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Preface 


PREFACE 


This manual describes the GUARDIAN/EXPAND operating system and applies 
to both Tandem NonStop Systems and Tandem NonStop II Systems. It 
assumes that you, the reader have basic knowledge of your system. The 
manual is organized into these sections: 


Section l. Introduction to EXPAND 


Section 2. Operator Interface: interactive functions such as 
editing remote files, copying files to a remote 
system, and running application programs on remote 
systems 


Section 3. Programmer Interface: writing application programs 
that access remote files. 


Section 4. Network Management: security, the NETMON utility 
program, and considerations for SYSGEN, CUP, PUP, 
and XRAY. 

Appendix A. File-Management Error Summary 


Appendix B. Network-related console messages and brief explanation 
of file management errors for line error diagnosis. 


Index 
Each section assumes knowledge of the corresponding topic on a single 
system. You should know how to edit a file before attempting to edit 


a remote file; you should know how to write programs for a NonStop 
system before attempting to write programs for a network. 
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RELATED DOCUMENTATION 


This manual is intended to be used in conjunction with other Tandem 
documentation--programming manuals, operating manuals, and so forth. 


Additional information about interfacing to an X.25 packet switching 
network is in the "AXCESS Data Communications Programming Manual" 
under the heading "X.25 Access Method". 


Additional information about performing line traces and obtaining line 
statistics is in the "AXCESS Data Communications Programming Manual" 
under the heading "Communication Utility Program (CUP)". 


Additional information about system generation is in your system 


operating manual under the heading "I/O System Configuration: Network 
Management". 


Of these other manuals containing information applicable to EXPAND 
users:, some apply only to Tandem NonStop System II computers, some 


apply only to original Tandem NonStop System computers, and some apply 
to both. 


Part 
Number Title 


82000 System Description Manual (for Tandem NonStop Systems) 

82077 Tandem NonStop II System Description Manual 

82019 GUARDIAN Operating Manual (for Tandem NonStop Systems) 

82075 GUARDIAN Operating System Operations Manual (for Tandem 
NonStop II Systems) 

82076 GUARDIAN Operating System Messages Manual (for Tandem 
NonStop II Systems) 

82014 GUARDIAN Programming Manual (for Tandem NonStop Systems) 

82074 GUARDIAN Operating System Programming Manual for Tandem 
NonStop II Systems) 

82015 General Purpose Procedures Programming Manual 

82084 AXCESS Data Communications Programming Manual 

82083 ENSCRIBE Programming Manual 

82018 ENVOY Programming Manual 

82081 Transaction Application Language Reference Manual 
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Preface 


SYNTAX CONVENTIONS IN THIS MANUAL 


The following is a summary of the characters and symbols used in the 
syntax notation in this manual. For distinctiveness, all syntactical 
elements appear in a typeface different from that of ordinary text. 


Notation 
UPPER-CASE 


CHARACTERS 


lower-case 
characters 


Brackets [] 


Braces {|} 


Comma , 


Arrows 


Punctuation 


Meaning 


Upper-case characters represent keywords and reserved 
words. If a keyword is optional, it is enclosed in 
brackets. If a keyword can be abbreviated, the part 
that can be omitted is enclosed in brackets. 


Lower-case characters represent all variable entries 
supplied by the user. If an entry is optional, 
it is enclosed in brackets. 


Brackets enclose all optional syntactic elements. 

A vertically-aligned group of items enclosed in 
brackets represents a list of selections from which 
one, or none, may be chosen. 


A vertically-aligned group of items enclosed in 
braces represents a list of required elements from 
which exactly one must be chosen. 


Commas separate elements in parameter lists. If 
parameters are omitted from a parameter list, place- 
holder commas must be inserted to indicate parameter 
position. However, if one or more parameters are 
omitted from the end of the list, the separating 
commas are not required. 


In procedure calls, a parameter that is a reference 
and that passes data to the procedure is followed by a 
right arrow (->); a reference parameter to which the 
procedure returns data is indicated by a left arrow 
(<-); a reference parameter capable of both sending 
and receiving data is followed by a double arrow 
(<->). A parameter passed by value has no arrow. 


All punctuation and symbols other than those described 
above must be entered precisely as shown. If any of 
the above punctuation appears enclosed in quotation 
marks, that character is not a syntax descriptor but a 
required character, and must actually be entered. 
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SECTION l 


INTRODUCTION 


The GUARDIAN/EXPAND operating system links as many as 255 
geographically distributed Tandem NonStop or NonStop II System 
computer systems to create a network having the same reliability, 
capacity to preserve data base integrity, and potential for modular 
expansion as a single system. 


Features of EXPAND include: 


ease Of operation and programming. EXPAND causes a network to 
appear to the user or programmer very much like a single system. 
Methods of accessing geographically remote devices, disc files and 
processes are identical to the corresponding procedures for 
accessing local files. If you know how to use the system, then you 
already know how to use a network of systems. 


pass-through routing. Systems need not be connected directly to 
one another to exchange data; in fact, messages may be passed 
through intermediate systems, allowing the number of communication 
lines in the network to be minimized. 


multi-line facility. A path can be made up of several lines where: 
a line is an actual physical communications wire and a path is the 
logical connection between two adjacent nodes in the EXPAND 
network. Multi-line increases network performance and reliability 
in the following manner: 


- Increased network performance. Allows simultaneous transmission 
over all lines within a path; thus increasing the overall 
bandwidth of the path. 


- Increased network reliability. Because multiple lines may exist 
in a single path, a single line failure will not bring down a 
path. Because lines may be distributed between multiple 
controllers, a single controller failure will not bring down a 
path; however, all controllers in a path must be in the same 
controller group--see SYSGEN in the GUARDIAN Operating Manual. 
In the event of either a single line or controller failure, the 
EXPAND error routine recovers messages in transit and reassigns 
the new best path. 


INTRODUCTION 


@e best-path routing. When multiple paths between systems exist, 
EXPAND routes data via the best path. If the status of the 
currently used best path changes--for example, following the 
failure or recovery of a communication line--message traffic is 
automatically rerouted along the new best path. 


@e modular expandability. Additional systems, up to 255, can be added 
to a network without disturbing existing systems. 


@ upward compatibility of existing application software. Application 
programs can be written in such a way that the network is 
transparent to them; existing programs require little or no 
modification to run on a network. 


@e X.25 compatibility. Any of the communication links between systems 
can be an X.25 public packet-switching network. 


e DATA EXCHANGED BETWEEN A and C is “PASSED THROUGH” B. 
e IF COMMUNICATION LINK BC SHOULD FAIL, MESSAGE TRAFFIC 
| BETWEEN A AND C IS AUTOMATICALLY REROUTED | 
ALONG PATH ABDC. 


Figure 1-1. A Network of Systems 
COMPONENTS OF EXPAND 
EXPAND is an extension of the GUARDIAN operating system. Its 
components include the Network Control Process, the End-to-End 
Protocol, Network Line Handlers, and a Network Monitor Program. 


Network Control Process (NCP) runs in each node of the network. The 
NCP functions include: 


e establishing intersystem connections 


@ maintaining network-related system tables, including routing 
information 


@e determining the best path to other systems 


@ monitoring and logging changes in the status of the network and its 
constituent systems. 


INTRODUCTION 


End-to-End protocol is a Tandem-defined, packet-switched protocol for 
the exchange of data between systems. The End-to-End protocol 
guarantees data integrity from sender to receiver regardless of how 
Many intervening systems are involved in the transfer. 


Two network line handlers (Direct Connect and X.25) manage a 
communication path and implement the End-to-End protocol. 


e The Direct Connect line handler, which acts as an I/O process, 
Manages one end of a full-duplex phone line between two systems. 


Figure 1-2 shows a network consisting entirely of Direct Connect line 
handlers. The path between system A and C is a multi-line connection. 
The system not shown could have additional communication paths to 
other systems, which would be accessed by sending packets through 
system B. Each system has multiple line handlers, but only one NCP. 


SYSTEM A 


LINE 
HANDLER 
NETWORK 
CONTROL } 
PROCESS 
SYSTEM B 


NETWORK 
CONTROL 
PROCESS 


ANOTHER 
SYSTEM 


SYSTEM C 


NETWORK 
CONTROL 
PROCESS 


Figure 1-2. A Network Containing Only Direct-Connect Line Handlers 
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INTRODUCTION 


@e the X.25 line handler provides the EXPAND link between systems 
connected through an X.25 network. The EXPAND X.25 line handler 
Manages the X.25 "virtual circuit" running in an X.25 AXCESS 
process. 


Figure 1-3 shows a system that connects to an X.25 network as well as 
to another system via EXPAND. Configuring such a system requires both 
EXPAND and AXCESS. The X.25 Access Process manages the physical 
communication line; the X.25 line handlers each manage one virtual 
circuit. 


The establishment of virtual circuits is controlled by the xX.25 Access 
Process. The Communication Utility Program (CUP) provides the X.25_ 
Access Process with the network address of the virtual ciruits, and 
associates the virtual circuits with the correct line handler. Refer 
to the "AXCESS Data Communications Programming Manual" for information 
regarding the X.25 Access. Process and CUP. 


The Network Monitor (NETMON) utility program provides users, at any 
system, with the ability to monitor the current state of the network 
in terms of: number of systems connected, number of cpu’s up on each 
system, line and path status, message traffic, etc. 


EXPAND (T9007) AXCESS (T9008) 


VIRTUAL | 
CIRCUITS | | 


X25 : 
ACCESS 
a PROCESS X25 NETWORK 


PROCESS 


Culities) ANOTHER 


| 
NETWORK 
CONTROL 
SYSTEM 


Figure 1-3. A System with Direct-Connect and X.25 Line Handlers 
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SYNTACTIC CONVENTIONS 


Before proceeding further, certain words used in this manual must be 
defined: 


network 


In this manual, a network consists of two or more Tandem NonStop or 
NonStop II Systems connected by communication paths. The paths can be 
full-duplex phone lines or X.25 virtual circuits. Each individual 
system, also called a node, runs under the GUARDIAN/EXPAND 

operating system. 


residence of files 


A disc file resides on a system if the file is located ona 

disc physically connected to that system; a device resides on a system 
if it is physically connected to that system; and a process resides on 
a system if it is running in a processor module of that system. 


Different partitions of a disc file can reside on different systems. 
(See "Alternate Key and Partitioned Files" in Section 3. 


local, remote, and network files 


With respect to any particular system, a local file is a file 

that resides on that system; a remote file is a file that 

resides on a different system; and a network file describes a 

file that can be either local or remote, when it is not necessary to 
make that distinction. The concepts of "local" and "remote" are 
relative to a particular system. 


SECTION 2 


OPERATOR INTERFACE 


This section describes the interface between an interactive user and a 
network; it assumes that the reader is familiar with the command 
interpreter and wishes to perform similar operations on a remote 
system, such as 

e editing a remote file 

@ running a program on a remote system 

@e duplicating a set of files from one system to another 


With a few exceptions, any operation performed on a system using the 
command interpreter can be performed on any system in a network. 


REMOTE SYSTEMS 


\EARTH.STERM 


\SATURN 
\NEPTUNE.SDATA 


Figure 2-l. Interactive Network Access 


OPERATOR INTERFACE TO EXPAND 
Network File Access 


NETWORK FILE ACCESS 


Interactive interface to the system consists of using the command 
interpreter, FUP, PUP, the Editor, and other subsystems to access 
files. Access to a file is via its symbolic file name. 


Access to a file in a network is achieved by qualifying a symbolic 
file name with the name of a system. For example, the command 


:EDIT \NEWYORK.SSYSTEM. SYSTEM. TEXTFILE 


edits the disc file SSYSTEM.SYSTEM.TEXTFILE, located on the system 
designated \NEWYORK. Similarly, the command 


:RUN \PARIS.MYPROG 


runs a program named MYPROG on the default volume and subvolume of 
the system designated \PARIS. 


Thus, a network file name consists of a local file name preceded by a 
system name. 


System Names 


Each system in a network is known by a system name. A system name 
consists of a backslash ( \ ) followed by one to seven alphanumeric 
characters. The first character must be alphabetic. Examples of 
legal system names are 


\DETROIT 
\Sys45 
\XYX 


A file residing on a system in a network is known by its system name, 
followed by the usual file name. Thus the disc file 
SMARKET.FRED.SALES, which resides on a disc drive connected to 
system \DETROIT, is named 


\DETROIT. SMARKET.FRED.SALES 


Network File Names 


Other forms of file names are extended to networks in the same manner. 
Examples: 

\DETROIT. STAPE ! a device name--in this case, a tape drive 
! residing on the system \DETROIT 


OPERATOR INTERFACE TO EXPAND 
Network File Access 


The length restrictions on network file names are: 


e Device names, including names of disc volumes, can have no more 
than six characters. 


e Process names can have no more than four characters. 
These restrictions are due to the inclusion of a system number in the 
internal form of file names. 


A network file name has this form: 


network disc file name 
\system name. network device name 
network process name 


where 


system name 
consists of one to seven alphanumeric characters, beginning 
with an alphabetic character. 

network disc file name 
is the same as the usual disc file name, except that the volume 
name is a dollar sign ($) followed by no more than six 
alphanumeric characters. 

network device name 
is a dollar sign ($) followed by no more than six alphanumeric 


characters. 


network process name 


is a dollar sign ($) followed by no more than four alphanumeric 
characters. 


OPERATOR INTERFACE TO EXPAND 
Network File Access 


Examples 


Table 2-1 shows examples of valid and invalid network file names. In 
each case, the file name in the right-hand column would be legal for 
local access, but is too long for remote access. This does not 
prevent a a system that belongs to a network from having a process 
named SSPOOL or a disc drive named S$DISCVOL. However, such file names 
can only be accessed locally; they cannot be accessed by any remote 
process or user. 


Table 2-1. Valid and Invalid Network File Names 


Type of Name Valid File Name Invalid File Name 


disc file SSYSTEM. SYSTEM. TAL SDISCVOL.SUB. YOURFILE 


device SLP SPRINTER 


process SSPL SSPOOL 


Default System Name 

Just as the VOLUME command specifies the default volume and subvolume 
names, the SYSTEM command designates a default system. The default 
system is implicitly appended to the front of every file name. The 
SYSTEM command has the form 

| SYSTEM [ system name j 


where 


system name 


designates the default system. Omitting the system name 
designates, as the default, the system on which your command 
interpreter is running. 


Examples: 


:SYSTEM \DETROIT 


makes \DETROIT the default system and causes filenames to be expanded 
in the network format. 


: SYSTEM 


removes any default system specification and causes filenames to be 
expanded in the local format. 
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Assuming that the local system is named \LOCAL and that the command 
interpreter is running on the local system then: 


:SYSTEM \LOCAL 
:STOP SABCDE 


would cause an "ILLEGAL FILE NAME" error, even though process SABCDE 
happens to be running locally, because the SYSTEM \LOCAL command 
interprets SABCDE as a network file name, subject to the 
four-character length restriction. 


However, the commands: 


:SYSTEM 
:STOP SABCDE 


would correctly interpret SABCDE as a local process name and the STOP 
command would be executed. 


Explicit and Implicit RUN Commands 


To run programs on a network, you must keep in mind that the program 
file must reside on the system where the program is to run. The 
program file must also be secured for the appropriate network access; 
you aS a user must have previously acquired network access rights to 
any systems on which you wish to run. Other than that, the explicit 
and implicit RUN commands work exactly as they do in a local system. 
For example, in the command 


:SYSTEM 

the local system is the default. The command 

: EDIT 

runs the Editor on the local system. The command 


:RUN MYPROG 


runs MYPROG, which is stored on the default volume and subvolume, on 
the local system. 


To run a program on the system \DETROIT, you would use the command 
:RUN \DETROIT.MYPROG 


The default volume and subvolume names remain in effect; thus, the 
command interpreter runs a program file named MYPROG, assuming that 
this file exists on the remote system. Note however, that the local 
system remains the default. Thus, if MYPROG references any files 
internally, it will try to get them from \LOCAL.filenames unless 
another system is explicitly specified. 
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Implicit run commands work the same way. Just as the command 
: EDIT 


implicitly runs a program whose object file is named 
SSYSTEM.SYSTEM.EDIT, the command 


:\DETROIT. EDIT 


implicitly runs a program whose object file is 

named \DETROIT.$SSYSTEM.SYSTEM.EDIT; because this file resides on 
system \DETROIT, and because programs run where their program files 
is located, the Editor runs on \DETROIT. 


Running Programs using the Default System Name 


Some more illustrations of the use of the SYSTEM command in 
conjunction with RUN and implicit RUN commands may be useful. The 
command sequence 


:SYSTEM \XYZ 
:EDIT YOURFILE 


runs an Editor in system \XYZ. If the default volume and subvolume 
are both DEFLT, then the file being edited 
is \XYZ.DEFLT.DEFLT.YOURFILE. The command sequence 


:SYSTEM \DETROIT 
:RUN MYPROG / IN \XYZ.SMKT.SUB.FNAME, OUT \SYS45.$SPL, CPU 3 / 


runs \DETROIT.DEFLT.DEFLT.MYPROG in processor 3 of system \DETROIT. 
The IN file is a disc file located on system \XYZ, and the OUT file is 
a process named $SPL running on system \SYS45. 


THE WHO COMMAND 


It is possible to forget what the default system is, and run a program 
remotely by mistake. You could type EDIT, for example, meaning to run 
the Editor in your own system, forgetting that you had previously 
issued a SYSTEM \DETROIT command. 


The WHO command helps you remember where you are. Its syntax is 
simply 


:WHO 
The WHO command displays the name of the home terminal (the terminal 
on which your command interpreter is running), the name of the command 


interpreter, its primary and backup CPUs; and the current default 
names. 
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The WHO command display takes the following form: 


HOME TERMINAL: $TERM 

COMMAND INTERPRETER: \XYZ.SCI66 PRIMARY CPU: 03 BACKUP CPU: O01 
CURRENT VOLUME: SMKT.SUBVOL CURRENT SYSTEM: \DETROIT 

USERID: 008,004 USERNAME: ADMIN.BILL SECURITY: AAAA 


If the SYSTEM command has not been used to specify a default system 
and naming conventions, then the "CURRENT SYSTEM" entry is omitted. 
Use the WHO command periodically to make sure you know where you are; 
in particular, use the WHO command before performing non-recoverable 
operations, such as purging files. 


SUBSYSTEM CONSIDERATIONS 


With certain exceptions, all Tandem subsystems accept file names in 
network form, allowing any operation to be executed on remote files. 


This section lists the exceptional operations that cannot be performed 
remotely. Also listed here are special considerations to be kept in 
mind when operating subsystems in a network environment. 


The absence of any particular subsystem from this list implies that 
all of its operations are valid in the network environment; a file 
name can be supplied in network form anywhere that the subsystems 
command syntax allows a file name. 


BACKUP and RESTORE 


The BACKUP program must be run in the system where the disc files to 
be backed up reside. However, the tape file and list file for BACKUP 
can be anywhere in the network. Therefore, to back up a set of files 
on the system \REMOTE, use the commands 


:SYSTEM \REMOTE 
:BACKUP / OUT \LOCAL.SLP / \LOCAL.S$TAPE , SMYVOL.FILES.* 


The same restriction applies to RESTORE. 


COMINT 


The commands RELOAD, XBUSUP, YBUSUP, XBUSDOWN, YBUSDOWN, SETTIME and 
TIME can only apply to the local system. 


Normally, all LOGON, LOGOFF, and process-creation commands are sent to 
the CMON process running in the same system as the command 
interpreter. For systems in a network, however, process-creation 
commands are sent to the CMON process in the system where the new 
process is to run, allowing an installation to control remote process 
creation. LOGON and LOGOFF commands are still sent to the CMON 
process in the command interpreter’s system. 
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EDIT 


To reduce the amount of text that must be sent over the communication 
path, you should run the Editor on the same system as the text file to 
be edited. For example, with the Editor and its text file residing on 
different systems, the command 


*LIST "XYZ" 


causes every line of text to be sent across the communication path. 
With the Editor and the text file on the same system, only the lines 
containing "XYZ" need be transmitted. If the text file is large, 
running the Editor in the same system as the text file causes a 
noticeable improvement in response time. 

PUP 

PUP commands can refer to only those devices residing on the system 
where PUP is running. Therefore, to list the free disc space 

on \REMOTE.SSYSTEM, the commands 


:SYSTEM \REMOTE 
:PUP LISTFREE SSYSTEM 


must be issued; you cannot type 
:PUP LISTFREE \REMOTE.SSYSTEM 


The CONSOLE command can specify a remote device as the operator 
console as in the following example: 


#CONSOLE \REMOTE.SLP 


SYSGEN 

The configuration file, list file, and work file can reside anywhere 
on the network. However, if the operating system image is to be 
placec directly onto disc (rather than tape, as is usually done) the 
disc volume specified must reside on the system where SYSGEN will run. 


SPOOLER 


The supervisor, collectors, and print processes belonging to a 
particular spooler must all run in the same system. 


A spool system can include remote devices. 


An application pr 
with this command 


:RUN MYPROG/ OUT \CHICAGO.SSPL / 
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PROGRAMMER INTERFACE 


This section describes how to write application programs that access 
remote files. It covers these topics: 


e overview of network programming 


e network file names and conversion between internal and external 
file names 


e network-related system procedures 
@ examples and considerations 


It is assumed that the reader already knows how to program the Tandem 
NonStop or NonStop II System, and is familiar with concepts such as 
file names, CRTPIDS, and the use of the file-management and 
process-control procedures. These subjects are discussed in your 
system programming manual. 


Writing a program that accesses remote files on a network is similar 
to writing an application that accesses only local files. A program 
need not be aware of whether the files it is accessing are local or 
remote unless it specifically needs to test for that condition. 


A local program (or application) is understood to be a program that 
accesses files only on the system on which it is running. A network 
program is a program that has access to files on systems other than 
the one on which it is running. As usual, a file can be a disc file, 
a peripheral device, or another process. 


A local application is written as if the network does not exist. If 
your application does not intend to access any remote files but is 
going to be run on a system that is part of a network, there are no 
special considerations. 
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SYSTEM NAMES AND SYSTEM NUMBERS 


Each system in a network is assigned a unique name and number. The 
system name consists of a backslash ( \ ) followed by one to seven 
alphanumeric characters. A system name qualifies a file name at the 
external (i.e., operator) level. For example, the system 

name \NEWYORK qualifies a file name passed as the IN parameter toa 
command interpreter RUN command: 


:TGAL/ IN \NEWYORK.$SYSTEM.REPORT.TEXTFILE , OUT SLP / 


Corresponding to the system name is the system number, an integer 
between 0 and 254 inclusive. The system number qualifies an internal 
file name. 


The application process does not need to know about specific system 
names and numbers. The FNAMEEXPAND and FNAMECOLLAPSE procedures 
perform the conversions automatically. 


To gain access to a file, a process passes the file”s symbolic file 
name to the OPEN file-management procedure, which returns a file 
number that can be passed to other file-management procedures. 


Remote files are accessed the same way. To specify a particular 
system as well as a file, a file name can optionally include a system 
number to identify the system. Such a file name is a network file 
name. A file name that does not include a system number is a local 
file name. 


To access a file on its local system, a process can pass the name of 
the file in locai form (which causes OPEN to assume that the local 
system is intended) or in network form, including the system number of 
the local system. 


To access a file on a remote system, a process must pass a network 
file name, with the appropriate system number, to the OPEN procedure. 
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NETWORK FILE NAMES (INTERNAL FORM) 
A file name in internal form (i.e., a 12-word array suitable for 


passing to the OPEN procedure) that is qualified by a system number is 
a network file name. Its form is 


network file name, INT:12, 


where 


network file name [0].<0:7> 


is an ASCII backslash (\) (octal 134). 


network file name [0].<8:15> 


is a system number (in octal). 


network file name [1:3] 


is a device name or process ID. 


network file name [4:7] 


subvolume name or #qualifier. 


file name [8:11] 


disc file name or subqualifier. 


NOTE 


The device name or process identifier in words [1:3] 
does not include the initial dollar sign ($) normally 
associated with a device name or process identifier. 


Because of the byte taken up by the system number, one less byte is 
available for the device name or process identifier. Therefore, the 
names of devices that can be accessed remotely consist of no more than 
six alphanumeric characters; names of processes that can be accessed 
remotely consist of no more than four alphanumeric characters. These 
restrictions are summarized in Table 3-l. 
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Table 3-1. Length Restrictions on Network File Names 


Type of Object Named Local Name Limit Network Name Limit 


device (including $ and 7 characters $ and 6 characters 
disc volume) 


process $ and 5 characters $ and 4 characters 


Figure 3-1 shows two examples of network file names in internal form, 
assuming that \LA is system number 3. 


a disc file: a process: 


\LA. SSYSTEM. SUBVOL. DISCFILE \LA. $PROC 


0 
1 


Figure 3-1. Network File Names in Internal Form 
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PROCESS IDs (CRTPIDs) 
A process is uniquely identified by its process identifier. The 
network forms of process identifier are shown below: 
Timestamp Form 
For the timestamp form, GUARDIAN assigns the process identifier when 
the process is created. The form of this type of process identifier 
is 

process id, INT:4, 


where 


process id [0].<0:1> 


is 2. 


process id [0].<2:7> 
is unused. 
process id [0].<8:15> 
is the system number if the system is part of a network, or 0 


otherwise. 


process id [1:2] 


is the low-order 32 bits of the creation timestamp, Or 0 fora 
system process. 


process id [3].<0:3> 


is unused. 


process id [3].<4:7> 


is the number of the CPU where the process is running. 


process id [3].<8:15> 


is the pin assigned by GUARDIAN to identify the 
process in the CPU. 
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Process-name Form 


The form of the process-name form of process identifier is 


process id, INT:4, 


where 


process id [0].<0:7> 


is an ASCII backslash (\) (octal 134). 


is the system number (in octal). 


process id [1:2] 


is the process name. 


process id [3].<0:3> 


is blank-filled. 


process id [3].<4:7> 


process id [0].<8:15> 
| 


| 
is the CPU number. | 
| 


process id [3].<8:15> 


is the pin. 


The process name, in words 1 and 2, can contain no more than four 
alphanumeric characters, the first of which must be alphabetic, and 
does not include the initial dollar sign ($) normally associated with 
a device name or process identifier. 
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CONVERSION BETWEEN EXTERNAL AND INTERNAL FILE NAMES 


Two procedures, FNAMEEXPAND and FNAMECOLLAPSE, perform 
internal/external file name conversion. Another procedure, 
FNAMECOMPARE, compares names that may be in different forms. 


FNAMEEXPAND converts a file name from external form to internal form, 
and expands partial file names using the default volume, subvolume and 
system. The conversion from external to internal form of a network 
file name includes changing the system name to the system number. 


FNAMECOLLAPSE converts a file name from internal form to external 
form. 


Both procedures convert local names to local names, and network names 
to network names. 


The FNAMECOMPARE procedure compares two file names within a local or 
network environment to determine whether these file names refer to the 
same file or device. For example, one name can be a logical system 
name or a device number while the other reference is a symbolic name. 


To be used in a TAL program, these procedures must be declared 
EXTERNAL. Like other system procedures, the external declarations can 
be specified with the compiler command 


?SOURCE SSYSTEM. SYSTEM. EXTDECS (FNAMEEXPAND , FNAMECOLLAPSE, FNAMECOMPARE) 
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FNAMECOLLAPSE Procedure 

The FNAMECOLLAPSE procedure converts a file name from its internal to 
its external form. The system number of a network file name is 
converted to the corresponding system name. 


The call to the FNAMECOLLAPSE procedure is 


eee FNAMECOLLAPSE ( internal name , 
external name ) 


length, INT 


contains, on return, the number of bytes in the external name. 


internal name, INT:ref:12 


is the name to be converted. If this is in local form, it is 
converted to external local form; if it is in network form, it 
is converted to external network form. 


external name, STRING:ref:26 or 34 
contains, on return, the external form of the internal name. 
If the internal name is a local file name, the external name 


contains up to 26 bytes; if a network name is converted, the 
external name contains up to 34 bytes. 


CONSIDERATIONS. It is the responsibility of the program calling 
FNAMECOLLAPSE to pass a valid file name in the internal name. Invalid 
file names cause unpredictable results. 

If the internal name is in network form and the system number in the 
second byte does not correspond to any system in the network, 


EXAMPLES. This procedure would convert the local internal name 


SSYSTEM SUBVOL MYFILE 

to SSYSTEM.SUBVOL.MYFILE. Where system number 5 is named \SF, and we 
use <%5> to denote octal 5 in the second byte, the procedure would 
convert the network internal name 


\<%5>SYSTEMSUBVOL MYFILE 


to the external form \SF.SSYSTEM.SUBVOL.MYFILE. 
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FNAMEEXPAND Procedure 
The FNAMEEXPAND procedure expands a partial file name from the 
compacted external form to the standard 12-word internal form used by 
file-management procedures. 
The call to the FNAMEEXPAND procedure is: 

FNAMEEXPAND ( external file 


internal file 
default names 


length, INT, 
is the length in bytes of the file name in the external file 
name. If an invalid file name is specified, zero is returned. 
external file name, STRING:ref:34 


re the file name to be expanded. The file name must be in ee 
form 


[\system name. ] 
[Svolume name.] [subvolume name.] disc file name delimiter 
Sdevice name delimiter 
S$logical device number delimiter 
where 
delimiter 
can be any character that would not be valid as part of 


an external file name, such as a comma, blank, or null 
character. 


internal file name, INT:ref:12 


is an array of 12 words where FNAMEEXPAND returns the expanded 
file name. This cannot be the same array as the external file 
name. 
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default names, INT:ref:8 


is an array of eight words containing the default volume and 
subvolume names to be used in file name expansion, where 


default names [0:3] 
is the default volume name, left-justified in the field. 
default names [4:7] 


is the default subvolume name, left-justified in the 
field. 


default names [0:7] corresponds directly to word [1:8] of the 
command interpreter startup message. See your GUARDIAN 
programming manual for the parameter message format. 


FILE NAME EXPANSION BY FNAMEEXPAND. This procedure returns a disc 
file name in this form: 


file name [0:3] = Sdefault volume name blank fill 
file name [4:7] = default subvolume name blank fill 
file name [8:11] = disc file name blank fill 


It returns "subvolume name.disc file name" in this form: 


file name [0:3] 
file name [4:7] 


file name [8:11] 


Sdefault volume name blank fill 
subvolume name blank £il 
disc file name blank fiil 


It returns "Svolume name.disc file name" in this form: 


file name [0:3] = S$volume name blank fill 
file name [4:7] = default subvolume name blank fill 
file name [8:11] = disc file name blank fill 


It returns "Svolume name.subvolume name.disc file name" in this form: 


file name [0:3] 
file name [4:7] 
file name [8:11] 


Svolume name blank fill 
subvolume name blank fill 
disc file name blank fill 
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It returns a device name in this form: 


file name [0:11] = Sdevice name blank fill 


It returns a logical device number in this form: 


file name [0:11] = $logical device number blank fill 


EXAMPLE. Using these declarations: 


STRING .EXT°NAMES [0:24] := "  FILEA SSYSTEM.FILEB ", 
-P; ! string pointer. 


INT .INFILE[0:11], 
~OUTFILE[0:11], 
.DEFAULTS[0:7] := "SVOL1 P 

"SVOL1 Me 


the FNAMEEXPAND procedure expands the external file names into a 
usable internal form: 

SCAN EXT*NAMES WHILE " " -> @P; ! skip leading blanks. 

@P := FNAMEEXPAND(P, INFILE, DEFAULTS) + @P; 

on the completion of FNAMEEXPAND, INFILE contains 

"SVOLL SVOLL FILEA " 

which is suitable for passing to the file-management CREATE, OPEN, 
RENAME, and PURGE procedures and to the process-control NEWPROCESS 
procedure. 

P is incremented by the number of characters in the external file 


name. 


SCAN P WHILE " " -> @P; ! skip intermediate blanks. 
CALL FNAMEEXPAND(P, OUTFILE, DEFAULTS) ; 


On the completion, OUTFILE contains 


"SSYSTEM SVOL1 FILEB m 
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NETWORK CONSIDERATIONS. If the external file name includes a system 


name, FNAMEEXPAND converts the system name to the appropriate system 
number. 


If the external file name does not include a system name, but a 
default system name is part of the DEFAULTS parameter, FNAMEEXPAND 
converts the external file name to a network internal file name having 
the correct system number. 

NETWORK EXAMPLE. Suppose that system \NEWYORK is assigned system 
number 4. Then the external file name \NEWYORK.SDATA.SUB.MYFILE is 
converted by FNAMEEXPAND to 

"\<%4>DATA SUB MYFILE " 

where <%4> denotes octal 4 in the second byte. 


If the system name does not exist in the network, FNAMEEXPAND supplies 
255 as the system number. 
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FNAMECOMPARE Procedure 
The FNAMECOMPARE procedure compares two file names within a local or 
network environment to determine whether these file names refer to the 
same file or device. For example, one name can be a logical system 
name or a device number while the other reference is a symbolic name. 
The file names compared must be in the standard 12-word internal 
format that is returned by FNAMEEXPAND. 
The call to the FNAMECOMPARE procedure is 

CALL 

status := FNAMECOMPARE ( file name 1, file name 2 ) 


where 


status, INT, 


is a value indicating the outcome of the comparison. Values 
for status are: 


-~l = (CCL), indicating that the file names do not refer 
to the same file. 
0 = (CCE), indicating that the file names refer to the same 
file. 
+1 = (CCG), indicating that the file names refer to the same 


volume name, device name, or process name on the same 
system; however, words [4:11] are not the same: 
file name 1 [4] <> file name 2 [4] FOR 8. 


A value less than negative one is the negative of a 
file-management error code. This indicates that the comparison 
is not attempted due to this error condition. 
That value returned from the program function determines the 
condition code setting. 

file name 1, INT:ref:12, 
is the first file name for the comparison. Each file-name 
array can contain either a local file name or a network file 
name. Definitions of file names are in your GUARDIAN 
programming manual. 


file name 2, INT:ref:12, 


is the second file name for the comparison. 
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CONSIDERATIONS. The arrays containing the file names for comparison 
are not modified. 


Alphabetic characters within qualified process names are not upshifted 
before comparison. 


If a logical device number format, such as $0076, is used for one file 
name, but not the other, the device table of the referenced system is 
consulted to determine whether the names are equivalent. This case is 
the only time the device table is used. All other comparisons involve 
only the examination of the two file names supplied. 


Some of the most common negative file-management error codes returned 
are: 


-13 = an illegal file name specification for either file name is 
made. 

-14 = the device does not exist. (See note.) 

-18 = no such system is defined in this network. (See note.) 

-~22 = a parameter or buffer is out of bounds. 


-250 = all paths to the system are down. (See note.) 


NOTE 


These negative file-management error codes indicate 
that only one of the file names is passed in logical 
device number format (requiring a check of the device 
table) and the file name represents a device connected 
to a remote network node. 


In a network node with a system number = 6, execution of the next code 
example returns a status of 0 and the condition code (CCE). Ina 
non-network system, execution of this code returns a status of 
negative one and the condition code (CCL). 


INT .FNAME1[ 0:11 J, 
-FNAME2[ 0:11 ], 


STATUS; 
FNAME] *:=" [ "STERM1L", 9 * [ " "] J]; 
FNAME2 “~:=" [ %56006, "TERM1 ", 8 * [ " "] J; r"\", 6, "TERML" 
STATUS := FNAMECOMPARE ( FNAME], FNAMEZ2 ); 
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In any system, execution of the next code example returns a status 
of +1, and the condition code (CCG). 


FNAME] “:=* [ "SSERVR #START UPDATING" ] 
FNAME2 *“:=° [ "SSERVR #FINISH UPDATING" ] 
STATUS := FNAMECOMPARE ( FNAME1, FNAMEZ2 ); 


e 
? 
e 
f 


In any system, execution of the next code example returns a status 
of zero and condition code (CCE). (The device name S$DATAX is defined 
as logical device number 13 at SYSGEN time.) 


FNAME] “:=* [ "$0013 ", 9 * [ " "Jj ]; 
FNAME2 “:=* [ "SDATAX", 9 * [ " "] ]; 
STATUS := FNAMECOMPARE ( FNAME], FNAME2 ); 


The FNAMECOMPARE procedure can also verify the specified file 
names as in the next code example: 


! assume all variables and procedures have been 
! properly defined and initialized elsewhere 

! 

! 


also assume LITERAL LEGAL = 0; 


IF FNAMEEXPAND ( EXTERNAL“NAME, INTERNAL“NAME, DEFAULT“NAMES ) THEN 
BEGIN 


! something reasonable was entered. 
IF FNAMECOMPARE ( INTERNAL“NAME, INTERNAL“NAME ) = LEGAL THEN 


! it may not exist, but looks okay. 
BEGIN 


! normal processing. 


END 
ELSE 


! the format is not legal. 
BEGIN 


! error processing. 
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EXAMPLE OF OPENING IN AND OUT FILES. Consider this procedure, which 
reads a startup message, opens the IN file, and returns the file 
number of the IN file (for clarity, no error-checking is performed 
following calls to system procedures) : 


INT PROC OPEN“ INFILE; 


BEGIN 

INT .REC*“BUF[0:32] := [ "SRECEIVE", 8 * [" " ]], 
REC*FNUM, 
IN* FNUM; 


! open S$RECEIVE, get startup message 
CALL OPEN( REC“BUF, REC*“FNUM ); 

CALL READ( REC“ FNUM, REC“BUF, 66 ) 
CALL CLOSE( REC*FNUM ); 


! open the IN file 

CALL OPEN( REC“BUF[9], IN” FNUM ); 
RETURN IN*FNUM; 

END; 


Any process that calls this procedure can communicate with its IN file 
without regard for the physical location of the file. Note that any 
existing program that reads its startup message and opens its IN and 
OUT files in this manner can handle network file names without 
modification or recompilation. 


EXAMPLE OF NETWORK USE OF FNAMEEXPAND. The next example demonstrates 
that the proper use of FNAMEEXPAND makes it unnecessary for an 
application program to be aware of the physical location of a file. 
The example procedure is called GET“ FILENAME. It accepts a file name 
from a terminal and expands the file name using the defaults. The 
calling program passes to GET“ FILENAME the file number of the terminal 
to be prompted and the current defaults obtained from the startup 
message. GET“ FILENAME returns the expanded internal file name in the 
parameter FILENAME. GET“FILENAME returns the number of bytes in the 
external name read from the terminal, or 0 if the terminal input is 
not a legal file name. 


The procedure keeps prompting the terminal until at least one nonblank 


character is input. For clarity, error detection and recovery are 
omitted. 
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INT PROC GET*FILENAME( TERM“FNUM, DEFAULTS, FILENAME ) ; 


INT TERM“FNUM, ! terminal file number 
- DEFAULTS, ! default volume and subvolume 
- FILENAME; ! internal file name goes here 

BEGIN 

INT COUNT*READ, ! number of characters read from terminal 
~-BUF[0:39]; ! terminal buffer 

STRING .BUFS := @BUF “<<* 1, ! string pointer to BUF 

-PTR; ! miscellaneous pointer 
WHILE 1 DO 
BEGIN 


! Prompt terminal for input until at least one character is read 
COUNT*READ := 0; 
WHILE NOT COUNT“READ DO 

BEGIN 

BUFS “:=* "ENTER FILE NAME: ee 


CALL WRITEREAD( TERM“FNUM, BUF, 18, 80, COUNT”READ ); 
IF <> THEN CALL ABEND; 
END; 


! insert a scan stopper and FNAMEEXPAND delimiter 
BUFS[ COUNT“READ ] := 0; 


! Scan off leading blanks 
@PTR := @BUFS; 
SCAN PTR WHILE " " -> @PTR; 


! If at least one nonblank character was input, call FNAMEEXPAND 
! and return; otherwise, loop back to the beginning. 
IF NOT SCARRY THEN 


RETURN FNAMEEXPAND( PTR, FILENAME, DEFAULTS ); 
END; ! outer loop 
END; ! proc GET*FILENAME 


On return, FILENAME contains the expanded internal file name suitable 
for passing to the OPEN procedure. The physical location of the file 


is entirely transparent to the application program. From its point of 
view, the sequence of events surrounding the call to GET” FILENAME is 


1. Get the defaults from the startup message. 


2. Open the terminal and pass the terminal file number, the defaults, 
and a 12-word FILENAME array to GET“ FILENAME. 


3. Pass the returned FILENAME to the OPEN procedure. 
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The calling program is unaware of whether the defaults, obtained from 
the startup message, are in local or network form. FNAMEEXPAND 
returns a network file name in FILENAME if either 


e the external name, read from the terminal, included a system name, 
or . 


@e the defaults included a system number. 


However, the calling program passes FILENAME directly to OPEN without 
caring whether the file is local or remote. 


SYSTEM PROCEDURES 
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The following summary lists the network-related system procedures by 
procedure name and function. 


Procedure 


CONVERT PROCESSNAME 
CREATEREMOTENAME 
GETPPDENTRY 


GETREMOTECRTPID 


GETSYSTEMNAME 


LOCATESYSTEM 


MONITORNET 


MYSYSTEMNUMBER 


MYTERM 


PROCESSINFO 


REMOTEPROCESSORSTATUS 


VERIFYUSER 


Function 


converts a process name from local to 
network form. 


supplies a process name that is unique for 
a specified system in a network. 


returns a particular entry in a specific 
system’s Paired Process Directory (PPD). 


returns the CRTPID, also known as the 
process ID, of a remote process whose CPU, 
PIN and system number are known. 


supplies the system name associated with a 
system number, and returns the logical 
device number of the line handler 
controlling the path to a given system. 


provides the system number corresponding to 
a system name, and returns the logical 
device number of the line handler 
controlling the path to a given system. 


enables or disables receipt of system 
messages concerning the status of 
processors in remote systems. 


provides a process with its own system 
number. 


provides a process with the file name of its 
"home" terminal. 


supplies process status information. 


supplies the status of processor modules in 
a particular system in a network. 


verifies, and optionally logs on, a user 
(described in Section 4 of this manual in the 
discussion of Programmatic Logon). 


Like all other system procedures, these must be declared EXTERNAL to a 
TAL program before they can be used. Appropriate EXTERNAL 
declarations can be included in a program with the compiler command 


?SOURCE SSYSTEM.SYSTEM.EXTDECS( procedure name , ... ) 
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CONVERTPROCESSNAME Procedure 


The CONVERTPROCESSNAME procedure converts a process name from local to 
network form. The call to CONVERTPROCESSNAME is 


CALL CONVERTPROCESSNAME ( process name ) 


where 


process name, INT:ref:3, 


is a process name beginning with a dollar sign ($); on 


return, this buffer contains the internal network form of the 
process name: a backslash (\) in the first byte, the calling 
process“s system number in the second byte, followed by the 
process name. 


If the process name does not begin with "S$", it is left 
unchanged. If it contains more than four characters, the 
file management system returns an error 20. 


EXAMPLE. An example of the action of CONVERTPROCESSNAME, assuming 
that MYSYSTEMNUMBER is 3: 


NAME *:=* "SPROC"; 
CALL CONVERTPROCESSNAME( NAME ); 


On return from the call, “name™ contains 


0 \ | $3 
1 P | oR 
2 O I. 2 
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CREATEREMOTENAME Procedure 


The CREATEREMOTENAME procedure supplies a process name that is unique 
for a specified system in a network. The call to CREATEREMOTENAME is 


CALL CREATEREMOTENAME( name, system number ) 


where 


name, INT:ref:3, 


returns a system-generated process name that is unique for the 
designated system. 


system number, INT:value, 


specifies the system for which the process name 
created. 


CONSIDERATIONS. These condition code settings result from use of the 
CREATEREMOTENAME procedure: 


< (CCL) indicates that the remote PPD could not be accessed. 
= (CCE) indicates that CREATEREMOTENAME was successful. 


A third setting, > (CCG), is not returned. 


CREATEREMOTENAME creates a process name in local form, consisting of 
"$Z" followed by three digits. A typical name would be "$2123". 


This name can be passed directly to the NEWPROCESS procedure to create 
a remote process having that name. It is unnecessary to append a 
system number to the process name, since the physical location of the 
program file determines where the new process will run. However, it 
is legal to append a system number, as long as the number matches the 
System number where the process is to be created. 


The creation of a process name does not make an entry in the remote 
system’s PPD. 


EXAMPLE. An example of the use of this procedure is: 


CALL CREATEREMOTENAME( NAME, SYS“NUM ); 
IF < THEN ... ! problems 
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GETPPDENTRY Procedure 


The GETPPDENTRY procedure returns a particular entry in a specific 
system’s Paired Process Directory (PPD). The call to GETPPDENTRY is 


where 


entry number, INT:value, 
specifies which PPD entry to return. The first entry is 0, 
the second is l, etc. 

system number, INT:value, 
specifies the system whose PPD is to be searched for the 
desired entry. 

PPD entry, INT:ref:9, 


returns the nine-word PPD entry specified by the given entry 


CALL GETPPDENTRY( entry number, system number, PPD entry ) 
and system numbers, where 
PPD entry [0:2] 
is the process name (in local form). | 
| 
| 


| 
| PPD entry [3] 
| is the CPU number and PIN of the primary process (CPU in 
| high eight bits, PIN in low eight bits). 

PPD entry [4] 


is the CPU number and PIN of the backup process (CPU in 
high eight bits, PIN in low eight bits). 


PPD entry [5:8] 


is the process identifier of the ancestor, if any. 


CONSIDERATIONS. These condition code settings result from use of the 
GETPPDENTRY procedure: 


< (CCL) indicates that the PPD in the given system could not be 
accessed. 

(CCE) indicates that GETPPDENTRY completed successfully. 

(CCG) indicates that there are no more entries in the PPD. 


Vv 


Programmer Interface--System Procedures 
GETPPDENTRY Procedure 


Tf the entry number is not currently being used, GETPPDENTRY returns 
CCE, and sets word 0 of PPD entry to 0. To check for that condition, 
an application could contain this code: 


CALL GETPPDENTRY( ENTRY“NUM, SYS“NUM, PPD*“ENTRY ); 
IF < THEN ... ; ! no more entries 

IF = AND PPD“ENTRY THEN ... ! found an entry 

ELSE ... ! try the next entry number 


GETPPDENTRY is related to LOOKUPPROCESSNAME (described in your 
GUARDIAN programming manual) in this manner: 


When you have the process name and want the PPD entry, use 
LOOKUPPROCESSNAME. When you want to pass the entry number, use 
GETPPDENTRY (use system number = MYSYSTEMNUMBER to access the local 
PPD). 


EXAMPLE. An application that needs to obtain all entries in the PPD 
of system 3 could use this code: 


INT ENTRY“NUMBER := -l, 
SYSTEM*“NUMBER := 3, 
DONE := 0, 


. PPD“ ENTRY [0:8]; 


DO 
BEGIN 
ENTRY“ NUMBER := ENTRY“NUMBER + 1; 
CALL GETPPDENTRY( ENTRY“NUMBER, SYSTEM“NUMBER, PPD“ENTRY ); 
IF = THEN ... ! do something with "PPD*“ ENTRY" 
ELSE DONE := 1; 
END 
UNTIL DONE; 
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GETREMOTECRTPID Procedure 


The GETREMOTECRTPID procedure returns the CRTPID, also known as the 
process identifier, of a process whose CPU, PIN and system number are 
known. The call to GETREMOTECRTPID is 


CALL GETREMOTECRTPID( pid, process id, system number ) 


where 


pid, INT:value, 


is the CPU number and PIN of the process whose process 
identifier is to be returned. 


process id, INT:ref:4, 


is an array of four words where GETREMOTECRTPID returns the 
process identifier of pid. If the system number specifies a 
remote system, the process identifier is in network form; if 
the system number specifies the local system, the process 
identifier is in local form. Both forms of process identifier 
are described in "Process IDs (CRTPIDs)", in this section. 


CONSIDERATIONS. These condition code settings result from use of the 
GETREMOTECRTPID procedure: 


< (CCL) indicates that the GETCRTPID failed because no such process 
exists, the remote system could not be accessed, or the 
process has an inaccessible name comprising more than four 


characters. 
= (CCE) indicates that GETREMOTECRTPID was successful. 


A third setting, > (CCG), is not returned. 


EXAMPLE. 


CALL GETREMOTECRTPID ( pid, crtpid, SYS*NUM ); 
IF < THEN ... ! problems 
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GETSYSTEMNAME Procedure 


The GETSYSTEMNAME procedure supplies the system name associated with a 
system number. The call to the GETSYSTEMNAME procedure is 


GETSYSTEMNAME ( system number, system name ) 


INT, 
returned one of these values: 


-l, indicating that all paths to the specified system are 
down 


0, indicating that the system is not defined 


a positive integer, indicating the logical device number of 
the line handler to the specified system. 


system number, INT:value, 


is the number of the system whose name is to be returned in 
system name, and will be between 0 and 254 inclusive. 


system name, INT:ref:4, 


contains, on return, the name corresponding to the system 
number. 


CONSIDERATIONS. If the local system is not part of a network, then 
CALL GETSYSTEMNAME( MYSYSTEMNUMBER, NAME ); 


returns all blanks to NAME. (MYSYSTEMNUMBER provides a process 
with its own system number). 


EXAMPLE. 


LDEV := GETSYSTEMNAME( SYS“NUM, SYS“NAME ); 
IF LDEV <= 0 THEN ... ! error 
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LOCATESYSTEM Procedure 


The LOCATESYSTEM procedure provides the system number corresponding to 
a system name, and returns the logical device number of the line 
handler controlling the path to a given system. The call to 
LOCATESYSTEM is 


| LOCATESYSTEM ( system number 


, { system name ] ) 


ldev, INT, 
is returned one of these values: 


e 1, indicating that all paths to the specified system are 


@ a positive integer, indicating the logical device number of 
the line handler to the specified system. In the case of 
multi-line, the LDEV returned is that of the path. 


system number, INT:ref, 


is the system number corresponding to the system name if the 
system name is provided. If the system name is not provided, 


down 
e 0, indicating that the system is not defined 
| | 
| | 
| the caller must provide the system number to be located. | 


system name, INT:ref:4, 


if present, specifies the system to be located, and causes the 
corresponding system number to be returned as the system 


number. 


EXAMPLES. 


! locate \NEWYORK, and return its system number 
SYS“NAME ~:=* \NEWYORK; 

LDEV := LOCATESYSTEM( SYS”“NUM, SYS“NAME ); 

IF LDEV > Q THEN ... ! success 


LDEV := LOCATESYSTEM ( SYS*“NUM ); 
IF LDEV <= 0 THEN ... ! problems 
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MONITORNET Procedure 


The MONITORNET procedure enables or disables receipt of system 


messages concerning the status of processors in remote systems. The 
call to MONITORNET is 


CALL MONITORNET( enable ) 
where 


enable, INT, 


is either 1, to enable receipt of messages, or 0, to disable 
receipt of messages. 


CONSIDERATIONS. A process that has enabled MONITORNET receives a 
system message via SRECEIVE whenever a change in the status of a 
remote processor occurs. The format of this message is: 


word [0] 

word [1].<0:7> 
word [1].<8:15> 
word [2] 

word [3] 


-8 

system number 

number of CPUs in the system 
current processor-status bit mask 
previous processor-status bit mask 


The processor-status bit mask has, in the bit corresponding to the CPU 
number, a one to indicate that the processor is up, and a zero to 
indicate that the processor is down or does not exist. 


MONITORNET provides notification of status changes for remote 


processors only. To receive notification of status changes for local 
processors, an application process still must call MONITORCPUS. 


EXAMPLE. 


CALL MONITORNET( 1 ); 
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MYSYSTEMNUMBER Procedure 


The MYSYSTEMNUMBER procedure provides a process with its own system 
number. The call to MYSYSTEMNUMBER is 


system number := MYSYSTEMNUMBER 


where 


system number, INT, 


returns the caller”s system number. 


CONSIDERATIONS. If the caller is running in a system that is not part 
of a network, MYSYSTEMNUMBER returns 0. Since 0 is a legal system 
number, a process which has to determine whether the system it is 
running in is part of a network should contain the code 


CALL GETSYSTEMNAME( MYSYSTEMNUMBER, name ); 


A return of all blanks in the name indicates that the system is not 
part of a network. 
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PROCESSINFO Procedure 


The PROCESSINFO procedure returns process status information. The 
call to the PROCESSINFO procedure is: 


cpu-pin 

process id ] 

creator accessor id ] 
process accessor id ] 
priority ] 

program file name ] 
home terminal ] 
system number ] 
search mode ] ) 


CALL PROCESSINFO 


be a i i i i i cee 


ae es esses ees ese 


where 


error, INT, 


is returned one of these values to indicate the outcome of the 
call: 


0 = status for process cpu-pin is returned. 
1 = process cpu-pin does not exist. Status for next higher 
cpu-pin is returned. process id [3] = cpu-pin is the 


process for which status is returned. 


2 = process cpu-pin does not exist and no higher cpu-pin 
exists. 


3 = cpu is down. 
4 = cpu does not exist. 


5 = the system specified by system number could not be 
accessed. 


99 = parameter error. 


cpu-pin, INT:value, 
specifies the process whose status is being requested where: 
cpu-pin.<0:7> is the cpu number. 


cpu-pin.<8:15> is the pin number. 
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process id, INT:ref:4, 


if present, is returned the process identifier of the process 
whose status is actually being returned. Note that this can be 
different from the process whose status was requested via 


if present, returns the creator accessor identifier of the 
process identifier (see "Network Security" in Section 4 for an 
explanation of the creator accessor identifier). 

process accessor id, INT:ref:l, 
if present, returns the process accessor identifier of the 
process identifier (see "Network Security" in Section 4 for an 
explanation of the process accessor identifier). 


priority, INT, 

if present, returns the execution priority of this process. 
program file name, INT:ref:12, 

if present, returns the name of the process identifier’s 


program fiie. 


home terminal, INT:ref:1i2, 


if present, returns the device name of the process identifier’s 
home terminal. If the home terminal resides on the local 
system, home terminal is in local form (begins with a dollar 
sign ($); otherwise, home terminal is in network form (begins 
with a backslash (\)). 


system number, INT:value, 
if present, specifies the system (in a network) where the 


process for which information is to be returned is running. If 


cpu,pin (see error). 
creator accessor id, INT:ref:l, 
| 
| 
| 
this parameter is omitted, the local system is assumed. 


search mode, INT:value, 


if present, is a bit mask that specifies one or more "search" 
conditions. If omitted, zero is used. 
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CONSIDERATIONS. On the call, the parameters to PROCESSINFO contain 
the value(s) for the search condition(s) and the bit fields in search 
mode specify the conditions being searched for (1 = condition must be 
met; 0 = don’t care): 


e search mode.<0> indicates that the searched process must match 
process identifier for three words. 


@e search mode.<l> indicates that the searched process must match 
the creator accessor identifier. 


@e search mode.<2> indicates that the searched process must match 
the process accessor identifier. 


e@e search mode.<3> indicates that the searched process must be equal 
to or less than priority. 


@e search mode.<4> indicates that the searched process must match 
program file name. 


@e search mode.<5> indicates that the searched process must match home 
terminal. 


If multiple search conditions are specified, then all must be met. 


If the system number specifies a remote system, the process identifier 
is returned in network form; otherwise, the process identifier is 
returned in local form. 


If the process’s home terminal is remote, home terminal is returned in 
network form; if the home terminal is local, home terminal is in local 
form. 


EXAMPLE. 


! return status for all processes run by me at my terminal. 


CAID := PROCESSACCESSID; 
CALL MYTERM ( HOMETERM ); 
PIN := QO; 
MODE := %42000; 
WHILE PROCESSINFO ( PIN , PID , CAID , PAID , PRI , PROG , 
HOMETERM , , MODE ) < 2 DO 
BEGIN 


PIN := PID [3] +1; 
END; 
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REMOTEPROCESSORSTATUS Procedure 


The REMOTEPROCESSORSTATUS procedure supplies the status of processor 
modules in a particular system in a network. The call to 
REMOTEPROCESSORSTATUS is 


status := REMOTEPROCESSORSTATUS ( system number ) 


where 


status, INT(32), 


returns the processor status in this format: The high-order 
word contains the number of processors in the remote system. 


If the remote system is nonexistent or unavailable, the 
high-order word is 0. 


The low-order word contains a bit mask for processor 
availability. If the processor is up, the corresponding bit is 


1; if the processor is down or nonexistent, the corresponding 
bit is 0. 


CONSIDERATIONS. The system number for a particular system whose name 
is known can be obtained from the LOCATESYSTEM procedure. 


The two words of status can be separated by "equivalencing" INT 
variables to the high and low-order words. For example, a TAL 
procedure that calis REMOTEPROCESSORSTATUS might contain these 
declarations: 


INT(32) STATUS; 


INT NUM*PROCESSORS = STATUS; ! high-order word 
INT BIT*MASK = NUM*“PROCESSORS + 1; ! low-order word 


"Equivalenced" TAL variables are explained fully in the Transaction 
Application Language Programming Manual. 


The bits in the low-order word are ordered from 0 to 15, from left to 
right: 


012 3 4 5 6 7 8 9 10 11 12 13 14 15 


REMOTEPROCESSORSTATUS can also be used to obtain the status of local 
processors, as shown here: 


INT(32) MY*PROCESSOR*STATUS; 
MY“PROCESSOR“STATUS := REMOTEPROCESSORSTATUS( MYSYSTEMNUMBER ) ; 
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PROGRAMMING CONSIDERATIONS 


This section presents considerations relating to network programming, 
including: 


@e network file names (external form) 
@ MYTERM procedure 

e command interpreter startup message 
@® remote process creation 

e saving file names 


e key-sequenced and partitioned files 


Network File Names (External Form) 


An application program that handles file names in their external form 
needs to allocate 34 bytes to handle a fully qualified network file 
name, as shown in Figure 3-2. 


\system name . $device or process . subvol . disc file name 


fo ™ 
1+ 7+ 1 + 1 + 6 + +j%1+B8B+H+t1 + 


34 


Figure 3-2. Allocation of 34 Bytes for Network File Name 


An example of a fully qualified network file name in external form is 


\NEWYORK. SORDERS. PARTS. INVNTRY 


MYTERM Procedure--Network Considerations 


If the home terminal is local, MYTERM returns the name of the home 


terminal in local form; otherwise, MYTERM returns the name of the home 
terminal in network form. 


Unlike the command interpreter startup message”“s IN and OUT files, the 
name returned by MYTERM is not affected by any SYSTEM command which 
the user may have issued. Therefore the command 


:SYSTEM \SF 


has no effect on MYTERM; if the home terminal is local, the home 
terminal name is in local form. However, this command would cause in 


IN and OUT files, even if they were local, to be passed to a process 
in network form. 
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Command Interpreter Startup Message 


The first task performed by an application process is to open its 
SRECEIVE file and read the command interpreter startup message. This 
message supplies the application process with the names of its IN 
file, its OUT file, and the current defaults. (The startup message is 
described in your GUARDIAN programming manual in the discussion of the 
command interpreter.) 


IN AND OUT FILES. The names of the IN and OUT files are passed in 
local or network form, depending on whether each file is local or 
remote. 


There is one exception to this rule: the name of a local file is 
passed in network form if the local system was explicitly specified 
(via the SYSTEM command) as the default system, and the file name was 
expanded using the default system. For example, suppose that the 
local system is \BUFFALO, and that these commands are issued: 


:SYSTEM \BUFFALO 
:RUN MYPROG / IN MYFILE / 


Any SYSTEM system name command causes the command interpreter to 
expand all partial file names using the default system. Therefore, 
MYFILE is expanded by the command interpreter using the default 
system \BUFFALO, and the IN file passed to MYPROG is in network form. 


An application process can either ignore or consider the physical 
location of its IN and OUT files. If the physical location of a file 
is not important, the process simply passes the file name to the OPEN 
procedure; if the physical location of the file is important, the 
process checks whether the first byte of the file name is a dollar 
sign or backslash ($ or \) and acts accordingly. 


DEFAULTS. The name of the default system, if one has been explicitly 
defined, is passed as part of the default volume name. For example, 
following the command interpreter commands 


: VOLUME S$VOL.SUBVOL 
:SYSTEM \LONDON 


assuming that \LONDON corresponds to system number 2, words [1:8] of 
the startup message sent to any process created by the command 
interpreter contain 

\<2>VOL  SUBVOL 


where <2> denotes octal (not ASCII) 2 in the second byte. 
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The default system is included in the default volume name only if a 
system has been explicitly specified via a SYSTEM system name command. 
The command 


: SYSTEM 


causes the default names to be passed in local form, as does the 
complete absence of a SYSTEM command. 


Observe that the command 
sSYSTEM \BUFFALO 


causes the default names to be passed in network form regardless of 
whether \BUFFALO is the local system. 


Remote Process Creation 


A process is created in a remote system the same way one is created in 
the local system: by passing the program file name to the NEWPROCESS 
procedure. There is one basic rule: a process*s program file must 
reside on the system in which the process is to run. 


If you want to create a remote process in a system that does not 
possess a copy of the program file, you must copy the program file to 
the remote system. 


Assuming that the appropriate program file resides on the remote 
system, creating the remote process is accomplished by passing the 
program file name to the NEWPROCESS procedure. For example, this code 
runs TAL aS an unnamed process on system \DETROIT, in CPU 2 at 
priority 140: 


STRING .PROC“NAME[0:27] := [ "\DETROIT.SSYSTEM.SYSTEM.TAL" , 0 ]; 
INT .PROGRAM*FILE[0:11], 
-PID, 


CALL FNAMEEXPAND( PROC*NAME, PROGRAM“FILE, DEFAULTS ); 
CALL NEWPROCESS( PROGRAM*“FILE, PRI, , CPU, PID, ERROR ); 
IF ERROR THEN ... 


CPU DEFAULTING. The CPU parameter of NEWPROCESS lets you specify 
the processor in which the new process is to run. Any remote 
processor can be used for process creation. 


If the CPU parameter is not specified, the new process runs in a 
processor selected from among those processors specified at SYSGEN 
time as being available to the network. 
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SENDING THE STARTUP MESSAGE. After a process is created, it must 

be sent a startup message. When formatting the startup message, the 
creator must take care to convert the IN and OUT file names and the 

default names to network form, so the new process can reference its 

files correctly. 


EXAMPLES. Suppose that the creator wishes to designate itself as the 
new process’s IN file. The creator could contain this code: 


! first, get my process ID 

CALL GETCRTPID( MYPID, MYPROCESSID ); 

! convert to network form 

CALL CONVERTPROCESSNAME( MYPROCESSID );3 
! move into startup message 
STARTUP“MSG[9] *:=* MYPROCESSID FOR 4; 


Note that if the creator is running as a named process, then 
CONVERTPROCESSNAME transforms the local name into network form. If 
the creator is running as an unnamed process, then its CRTPID already 
specifies the system number (in the second byte) and 
CONVERTPROCESSNAME leaves the CRTPID unaltered. 


The code in the next example could be used to specify the creators 
own OUT file as the new process’s OUT file. Assume that OUTFILE 
contains the creator’s OUT file name as obtained from its startup 
message. 


STRING .OUTFILES := @OUTFILE “<< 1; 


IF OUTFILES = "$" THEN i! change it to network form, 
! using my system number 


BEGIN 

OUTFILES[7] *=:* OUTFILES[6] FOR 7; 
OUTFILE := "\" *<<* 8 + MYSYSTEMNUMBER; 
END; 


If the first byte of OUTFILE contained a backslash (\) character . 

(indicating a network file name), or neither a dollar sign ($) nor a 

backslash (indicating the CRTPID of an unnamed process), then OUTFILE 
would be left unchanged. 


Similar code could ensure that the default names are passed correctly. 


Other cases--for example, the new process’s OUT file being specified 
as a process in some other system--must be handled on an individual 
basis. Keep in mind that the new process will assume that file names 
in iocai form are iocai files. If this would cause incorrect resuits, 
then the creator must modify the startup message before sending it. 
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Saving File Names 


Programs that save network file names should save the file names in 
external form. File names in external form should be converted to 
internal form immediately before opening the file. The reason is that 
conversion from system name to system number depends on the current 
state of the communication path to the remote system: if the path is 
down, the system name is converted to system number 255, an illegal 
value that causes OPEN to fail. 


Alternate-key and Partitioned Files 


An alternate-key file can be made to reside on a different system than 
the primary file by listing the alternate-key file”s location in 
network form in the alternate key params array when the primary file 
is created, and passing the file name in network form to the CREATE 
procedure to create the alternate-key file. Passing a local file name 
to CREATE causes an alternate-key file to be created on the same 
system as the primary file, not on the default system. 


Any file, including an alternate-key file, can be partitioned across 
system boundaries. To create a partitioned file having partitions on 
different systems, follow the same procedure used to create a 
partitioned file, as described in the ENSCRIBE Programming Manual. 
The partition params array is used in the same way. However, instead 
of supplying the Svolume on which a partition is to reside, you must 
supply 


\system number volume name 
where the "S$" is omitted from the volume name. Supplying a $volume 


name without a system number causes the partition to be created on the 
same system as the primary partition, not on the default system. 
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SECTION 4 


NETWORK MANAGEMENT 


This section presents information relevant to the management of a 
network. Topics included are: 


@ best-path determination 
@e Network Monitor (NETMON) utility program 
@e network security 


e items to consider when using SYSGEN, CUP, PUP and XRAY 


BEST-PATH DETERMINATION 


Intersystem messages are always sent via the best path between the two 
systems. The determination of the "best" path is made by assigning 
weight factors based on line speed to the communication lines, and 
computing the sum of the weight factors along each possible path. 


The multi-line facility allows all lines in a path to be used 
simultaneously, thus the effective bandwidth will be the sum of the 


bandwidths of all lines in the path; that is, multiple packet messages 
are distributed over multiple lines. 


In the event of a line failure, the NCP updates its NETMAPS to reflect 
the decrease in path bandwidth; likewise reactivation of the line 
updates the NETMAPS to reflect the increase in bandwidth. [In the 
event of a controller failure, the NCP updates its NETMAPS to reflect 


the decrease in bandwidth for all lines connected to the failed 
controller. 


Each line has a configured line weight (SYSGEN RECSIZE), as shown in 
Table 4-1. The line handlers for the neighbor paths establish the 
weight factor value during path initialization and whenever a line 
failure or activation occurs. For routing purposes, the neighbor NCPs 
agree to use the slower line speed (larger value). The following 


equation shows how the weight factor for a multi-line path is 
determined: 
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path WF = WF conversion factor 
WF conv fact WF conv fact WF conv fact 
—------------ Se ee ae 
linel WF line2 WF line n WF 


For example, the weight factor for a multi-line path consisting of 


three lines with each line’s speed configured for 4800 baud and weight 
factor of 47 is: 


path WF = 224000 
224000 224000 224000 
i easier wrenwreiowies , ee eer 
47 47 47 
= 224000 


4765 + 4765 + 4765 


224000 = 15.7 = 16 


This results in converting the weight factors to line speeds, adding 
the line speeds together to get a path speed, and then dividing the 
weight factor conversion factor by the path speed to get the path 

weight factor (number of seconds required to transmit 224000 bytes). 


Table 4-1. Line Weights According to Line Speed 


Line Speed Weight Factor 


2400 baud 93 
4800 baud 47 
9600 baud 23 
19200 baud 12 
50000 baud 5 
56000 baud 4 
224000 baud 1 


The weight factor represents the number of seconds it takes to 
transmit 224000 bits of data across a given line. For example, it 
takes 47 seconds to transmit 224000 bits across a 4800-baud line. 
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Consider this network: 


Figure 4-1. Weight Factors Based on Line Speed 


In Figure 4-1, a message from node A to node D (without multi-line) 
would be sent via the path A -> B -> C => D. The total of the weight 
factors along this path (23 + 4 + 12 = 39) is less than the total of 
the weight factors along any other path. However, if a multi-line 
connection is made between node A and node E, by adding two 4800-baud 
lines, its weight factor = 16. Thus, with multi-line, a message from 
node A to node D takes the path A -> E -> D. The total weight factor 
along this path is (16 + 12 = 28). 


Each line“s weight factor is specified via SYSGEN. It is not 
necessary to use the values given in the table. If you want to force 
message traffic to travel over a slow path (for whatever reason), you 
can configure a small weight factor for the line. 


For the best-path routing scheme to work, each node must know about 
the current status of the network. The Network Control Process in 
each node maintains routing tables that enable messages to be routed 
correctly. Changes in the status of the network are propagated 
throughout the network by the exchange of messages between the NCPs in 
neighboring systems. 


Suppose, in the example above, that the communication Line between B 
and C fails. C informs D of the failure; then D informs E, and E 
informs A and B. Meanwhile, B informs A and E, A informs E, and E 
informs A and D. Each system updates its routing tables as it becomes 
aware of the change in network status, allowing all message traffic to 
be routed correctly. The same scheme of informing one’s neighbor is 
used when a communication line becomes available or a new system is 
added to the network. 
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In the case of multi-line, the general network routing procedure 
remains the same with one exception. A line ready or not ready 
condition causes an update to the NETMAPS to reflect the change in 
the path weight factor; however, a line down does not necessarily 
mean that the path is down (weight factor of infinity). In fact, the 
new best path may indeed be the same as the original path. 


The method of informing all nodes about routing changes is implemented 
in such a way that no system ever becomes confused about where to send 


a message; packets are always routed correctly regardless of any 
sequence of catastprophes. 


NETMON Network Utility 


The network monitor program NETMON lets one system within a network 
act as a center for monitoring the network. The NETMON program 
provides: 

@e logging of changes in network status 

e logging of changes in processor status at remote systems 

e a display of changes in processor status at remote systems 


@e a display of network traffic 


The command to run NETMON is: 


NETMON [ /{run parameter},.../ ] [command] | 


where run parameter takes the form: IN command file, OUT list file, 
or NAME [ S$process name ]. 


specifies a disc file, terminal, or process where NETMON reads 
commands. NETMON reads 132-byte records from the command file 
until it encounters the end-of-file. Only one command is 
permitted per record. If this option is omitted, the home 
terminal is used. 


OUT list file 


specifies an existing disc file, terminal, or process where 
NETMON directs its listing output. If the command file is a 
terminal, the list file must be the same terminal. If this 
option is omitted, the home terminal is used. 


IN command file 


Network Management--NETMON Network Utility 
NETMON Command 


NAME [ $process name ] 


specifies a symbolic name to be assigned to the new process. 
This option is necessary if the BACKUPCPU command is issued. 
If the $process name is omitted, the operating system 
generates a name for the new process. If this option is 
omitted, the process is unnamed. 


command 


is one Or more NETMON commands separated by semicolons. If a 
command is included, NETMON executes the command, then 
terminates. If the DISPLAY command is embedded in the command 
string, the DISPLAY command is terminated by the BREAK key. 
Any subsequent commands in the string are then executed before 
NETMON terminates. 


EXAMPLES. In this example, NETMON starts and prompts for commands: 


: NETMON 


NETWORK MONITOR -— T9007EO2 - (O1LJULY81) 
> 


In the next example, NETMON starts, executes a command to begin 
central logging, and terminates: 


:NETMON LOGCENTRAL ON 
NETWORK MONITOR - T9007E02 -— (O1JULY81) 
CENTRAL LOGGING INITIATED 


In the next example, NETMON starts, executes a command to display the 
processor status of the systems in the network, sends the data to the 
printer $LP, and terminates: 


:NETMON /OUT $SLP/ CPUS 
NETWORK MONITOR —- T9007E02 - (O1JULY81) 


In the next example, NETMON starts and displays the network traffic 
and processor status for selected systems: 


:NETMON /NAME/ BACKUPCPU3;ADD ALL;DISPLAY 
NETWORK MONITOR —- T9007E02 - (O1JULY81) 


NETMON then clears the screen and begins the display. The display 
continues until the BREAK key is pressed. 
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EXIT Command 
The EXIT command terminates NETMON. Then, the command interpreter 


prompt appears. Control-Y also terminates NETMON. 


FC (Fix Command) 


The FC command lets you edit or repeat a command line. When this 
command executes, it displays the previous command line and prompts 
with a period. FC accepts three subcommands: 


e I inserts one or more characters 

@e R replaces one or more characters 

@e D deletes one or more characters. 

FC again displays the command line after the line is edited, and 
prompts for another subcommand. FC terminates when it receives only a 
Carriage return. The "COMINT" (command interpreter) section of your 
system operating manual describes the FC command in detail. 


EXAMPLE. 

: NETMM 

FILE ERROR 11 

‘ io (The I command inserts the O before the M) 
‘ rN (The R command replaces the M with an N) 


‘ (A carriage return terminates the FC command) 
NETWORK MONITOR - T9007D05 - (010CT80) 
> 


BREAK Key 


When the BREAK key is pressed, the currently executing command aborts. 
The BREAK key also is the only way to terminate the DISPLAY command. 
If no command is executing, the command interpreter resumes control. 
The command interpreter”s PAUSE command lets NETMON resume. 


Control-Y 


Control-Y terminates NETMON, then the command interpreter prompt 
appears. The EXIT command also terminates NETMON. 
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NETMON Commands 


This subsection describes the commands that let you operate NETMON. 
These commands are summarized below and then described in detail. 


ADD 


BACKUPCPU 


CPUS 


DELETE 


DISPLAY 


EXIT 
FC 


HELP 


LOGCENTRAL 


PATHS 


MAPS 


PERIOD 


PROBE 


SHOW 


STATS 


THRESHOLD 


adds one or more systems in the network to the display 
list. 


specifies the processor where the NETMON backup process 
is run. 


displays the status of the processors for all systems 
known by the specified system. 


deletes one or more systems in the network from the 
display list. 


shows the network traffic and processor status of the 
selected systems. 


terminates the NETMON program. 

(fix command) edits and reexecutes a command line. 
provides command syntax for all NETMON commands. 
starts or stops central logging at the local system. 


displays the status of a selected path along with the 
status of lines within the path. 


displays the status of the network as seen from the 
selected system. 


sets the sample interval time in seconds. 


displays the current paths from remote systems to the 
selected system. 


displays the systems selected with the ADD command. 
displays detailed statistics for the selected system. 


determines when to blink the rate of packets line in the 
display shown with the DISPLAY command. 
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ADD Command 


The ADD command adds one or more systems to the list of systems to be 
displayed. The form of this command is: 


ADD ALL 
system [, syatencudd| 
where 


ALL 


specifies the first 16 systems in the network because only 16 
systems fit on a screen for a display. 


system 


is specified either as a system name (e.g., \DALLAS) or a 
system number (e.g., 3). 


EXAMPLE. 


ADD \DALLAS,3,\WASH 
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BACKUPCPU Command 

The BACKUPCPU command specifies the processor where the NETMON backup 
process is run. This command is useful when a terminal is constantly 
displaying network information; it is not useful when using NETMON 


interactively. Moreover, the NAME option must be included when NETMON 
is started. The form of the command is: 


BACKUPCPU [cpu] 


where 


cpu 


specifies the processor in which to run the backup NETMON 
process. If this parameter is omitted, any existing backup 
NETMON process will be stopped. 


EXAMPLE. 


BACKUPCPU 3 
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CPUS Command 


The CPUS command displays the status of the processors in all the 
systems that are known by the specified system. The NCP revision 
level also is displayed for each system. The form of the command is: 


CPUS 


[ system ] 


where 


system 


is specified either as a system name (e.g., \DALLAS) or a 


system number (e.g., 3). If this option is omitted, the local 
system is assumed. 


The form of the display is: 


SYSTEM 0<--CPU STATES-->15 NCP LVL 
sss system nnnn,nnnn,nnnn,nnnn x 
sss(system) nnnn,nnnn,nnnn,nnnn -- 
sss system nnnn,;nnnn,nnnn,nnnn x 
where 

Sss system 


nnn 


is the number and name of one of the systems known to the 


selected system. The selected system”s name is enclosed in 
parentheses. 


n,nnnn,nnnn,nnnn 


is the status of each processor in a system. 1 indicates the 
processor is active; 0 indicates it is inactive. A period 
represents a nonexistent processor. NOT CONNECTED means a 
known system is not attached to the network currently. 


is the level of the network control process (NCP). The NCP 
level for the selected system is shown as a dash. This number 
is used by Tandem personnel. 
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EXAMPLE. In this example, system 3, the selected system, has 12 
processors that are all active. The system name \TS is enclosed in 
parentheses and the NCP level is a dash. System 11 has four 
processors, one Of which is inactive. System 5 currently is not 
attached to the network. 


>CPUS 3 
NETCPUS AT \TS (003) #PATHS=06 TIME: 4 SEP 1980, 9:34:43 
SYSTEM 0<--CPU STATES-->15 NCP LVL 
2° \CUPRINO. (2111 pos ccigeciug esse 1 
3 (\TS ) 1111,1111,1111,.... == 
4 \DALLAS A ee ee ee 1 
5 \CHICAGO NOT CONNECTED 
6 \NEWYORK l1ll.,..ccpeccezoece 3 
7 \QA Llllypecccpececzeccn 1 
8 \LA Liss vase pe eepaae's 1 
9 \CORP 1111,1111,..6c;20. 2 
10 \MFG LIL, llc pew cc pecee 1 
L1 \TORONTO 1110,...cpeccezeeess 4 
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DELETE Command 


The DELETE command removes one or more systems from the list of 
systems to be displayed. The form of this command is: 


DELETE ALL 
system [ | 


where 


ALL 
specifies all the systems that are currently selected. 
system 


is specified either as a system name (e.g., \DALLAS) or a 
system number (e.g., 3). 


EXAMPLE. 


DELETE ALL 
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DISPLAY Command 


The DISPLAY command starts the display mode of NETMON. This command 
is designed to function on a page-mode terminal; the display is 
unreadable on other devices. The display shows network traffic and 
processor status for the systems specified with the ADD command. The 
First numbers of the display are not shown until the first sample 
period has passed. The form of the command is simply: 


| DISPLAY | 


with no options. 


The format of this display is: 


\systemx (sss) \systemx (sss) \systemx (sss) \systemx (sss) 
tttt (pppp) tttt (pppp) tttt (pppp) tttt (pppp) 
avg uuuu (qqqq) avg uuuu (qqqq) avg uuuu (qqqq) avg uuuu(qqqq) 


SSSSSSSSSSSSSSSS SSSSSSSSSSSSSSSS SSSSSSSSSSSSSSSS SSSSSSSSSSSSSSSS 


where 


\systemx (sss) 


is the name and number of one of the systems selected for 
status and traffic monitoring. 


tttt 


is the number of packets sent by and through the system during 
the sample period. | 


PPPP 


is the number of packets that are pass-through traffic. The 
tttt(pppp) line blinks whenever the difference between sample 


periods reaches the percentage specified with the THRESHOLD 
command. 


uuuu (qqqq) 


represents the weighted averages for the network traffic rate. 
uuuu is the average number of packets sent by and through the 
system during the sample period. (qqqq) is the number of 
packets that are pass-through traffic. 


BIG LW LA msQataycinmocie 


DISPLAY Command 


SSSSSSSSSSSSSSSS 


EXAMPLE. 


“~ BN dod 2b 273N7 kN Ne WA LLEALEQWA LANA 


is the last reported processor status for the system. 


the 16 letters is replaced with l, 
an active processor; 0 represents an inactive processor; a 
hyphen represents a nonexistent processor. 


0, or hyphen. 


whenever a change in processor status is detected. 


it returns no statistics. 


>DISPLAY 


This example of the network status display is abbreviated. 
The actual display has four systems across and four systems down. 
this example, \DALLAS is not currently connected to the network. 
Thus, 


NETWORK STATUS DISPLAY AT \TS (003) 


\SAA (000) 
2049 (0000) 
avg 1215(0000) 


\TS (003) 
559 (0004) 
avg 385(0003) 


111111---------- 


TIME: 28 APR 1981, 


\SAB (001) 
34 (0000) 
avg 22 (0000) 
0011----------~--- 
\DALLAS (004) 
000=-eeSe-e56 55 
16:39:23 


\CUPRTNO (002) 
639 (0062) 
avg 474(0057) 


\QA (007) 
1990 (0661) 
avg 1008(0293) 


l represents 


This line blinks 
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HELP Command 
The HELP command lists the syntax or provides a brief description of 
the NETMON commands. The form of the command is: 
HELP ALL 
command 


where 


ALL 


displays the syntax and describes all NETMON commands. This is 
the default. 


command 


specifies the command for which the syntax and description is 
displayed. 


EXAMPLE. 


>HELP 


ADD < system list > 

BACKUPCPU [ cpu # ] 

CPUS <system > 

DELETE < system list > 

DISPLAY 

EXIT 

FC 

HELP [ < command name > | ALL ] 
LOGCENTRAL [ ON | OFF ] 

MAPS [ < system > ] 

PATHS [ < system > J], [PATH < pathnum > ] 
PERIOD [ < sample interval > ] 

PROBE [< from system >], [PERIOD < interval >], [SYSTEM < to system >] 
SHOW 

STATS [ < system > ] 

THRESHOLD [ < threshold > ] 


>HELP MAPS 


MAPS [ < system > ] 
Displays the NETMAPS for selected system. Default local system. 


Network Management--NETMON Commands 
LOGCENTRAL Command 


LOGCENTRAL Command 


The LOGCENTRAL command either starts or stops central logging of 
network messages on the local system. The form of this command is: 


gs ong pe aw a ey a pa a ee ge 


LOGCENTRAL ES 
ON 


where 


OFF 


stops central logging at the local system. 


Starts central logging at the local system. If you specify 
neither ON nor OFF, the name of the system performing the 
central logging is displayed. 


The network can create a lot of logging information if either a path 
or a system fails. Because the operator console usually is a slow 
printer, logging this information can tie up allocation of system 
resources at the receiving operator process. Disabling log messages 
at the local system, through PUP CONSOLE, ENABLE/DISABLE, reduces the 
amount of unnecessary traffic queued up at the operator process. 
When central logging starts or stops or when the status of any network 
processor changes, a message is logged on all of the systems in the 
network. For example: 
34 {...} NET: LOGGING AT SYS sss 

indicates that central logging was initiated 
35 {...} NET: LOCAL LOGGING RESUMED 

indicates that central logging was terminated 
48 {...} NET: SYS sss CPU STATUS ssssssssssssssss 

indicates a change in processor status 

where 


Leccet 


indicates the position for the date and time. 
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sss 


is the system number. 


SSSSSSSSSSSSSSSS 


is the last reported processor status for the specified system. 


CONSIDERATIONS. If LOGCENTRAL is on, the NCP sends log messages to 
the logcentral system; however, no logging occurs to the local 
operator process (disc-resident operator log). On the other hand, if 


the path to the logcentral system is down, the messages are logged to 
the local operator process. 
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MAPS Command 
The MAPS command displays the status of the network as seen from the 
selected system. This command provides the ability to look at the 


network from any system even though NETMON is running elsewhere. The 
form of the command is: 


MAPS [ system ] 


where 


system 


is either a system name or a system number. If this option is 
omitted, the local system is assumed. 


This command displays as many as six paths per line on devices with 
fewer than 132 columns and as many as ten paths per line on devices 
with 132 or more columns. If the selected system has more paths than 
will fit on one line of the output device, the additional paths are 
shown on the next line and a blank line is inserted between systems. 
The form of the display is: 


NETWORK MONITOR - T9007D05 - (010CT80) 


NETMAPS AT <system>(sss) #PATHS=<nn> TIME: <date>,<time> 


SYSTEM TIME (DISTANCE) BY PATH 
sss <systema> ttttt(dd) ttttt(dd)* ttttt(dd) ttttt(dd) ttttt(dd) 
Sss <systemb> ttttt(dd) ttttt(dd)* ttttt(dd) tttet(dd) ttttt (dd) 


sss <systemc> ttttt(dd) ttttt(dd) ttttt(dd)* ttttt(dd) ttttt(dd) 


PATHS NEIGHBOR LDEV STATUS 

<pn> isiiweee- (SSS) XX NOT READY (err) 
<pn> <system> (sss) XxX READY (cpu,pin) 
<pn> <system> (sss) xx READY (cpu,pin) 
where 


system (sss) 


is the name and number of the system specified in the MAPS 
command. 


nn 
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is the number of communication lines radiating from the 
selected system. This number indicates the number of rows and 
columns under TIME (DISTANCE) and the number of paths listed at 
the bottom of the display. 


date, time 


is the date and time at which the display was made. 


sss <systema> 


is the number and name of one in a list of systems in the 
network. 


ttttt (dd) 


pn 


is the time(ttttt) and distance (dd) between systems in the 
network and the selected system. Each row and column 
represents a path that corresponds to the paths listed at the 
bottom of the display. For example, the third column in the 
first row represents the time and distance required to reach 
systema through path 3. An asterisk (*) shows that systema is 
connected to the selected system through this path; a plus sign 
(+) indicates that a connect request is outstanding, but the 
connection has not yet been established. A system that cannot 
be reached through a path is indicated by 32767(--). 


ttttt represents the sum of the line-speed time factors that 
are specified for system generation. The smaller numbers 
represent faster lines. 


dd represents the number of node-to-node paths traveled to 
reach systema through a particular end-to-end path. 


is the number of a path corresponding to a column under TIME 
(DISTANCE). 


system (sss) 


is the name and number of the system directly connected to the 
selected system. 
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XX 


is the logical device number of the line handler. In the case 
of multi-line, it is the logical device number of the path. 


(err) 


is the file-system error for a path that is not ready. This 
error usually is 66 for a device downed by the operator or 
modem loss or 248 for a nonresponding remote system. In the 
case of a multiline path, if all lines are down, the error 
number will be for the fastest line in the path. For a more 
detailed description of the error, use the PATHS command. 


(cpu,pin) 


is the processor and process identification number of the 
current primary process of the line handler. 


EXAMPLE. This example shows the MAPS command issued for system 3, 
which is system \TS. This system has five paths radiating from it. 
The last column, filled with 32767(--), indicates one path which is 
not ready. The row filled with this number indicates that system 5 is 
not available. An asterisk next to the time and distance shows how 
many systems are connected through a path to the selected system. By 
looking at the time and distance column for a particular path, the 
presence of an asterisk indicates which systems are currently 
connected through that path. If a system can be reached through more 


than one path, the asterisk indicates the shortest route to that 
system. 
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>MAPS 3 


NETWORK MONITOR - T9007D05 - (010CT80) 


NETMAPS AT \TS (003) #PATHS=05 TIME:4 SEP 1980, 9:38:59 

SYSTEM 

2 \CUPRTNO 10 (02) 5 (01) * 51(03) 99(03) 32767(--) 
4 \DALLAS 28 (02) * 33 (03) 74 (04) 122(05) 32767(--) 
5 \CHICAGO 32767(--) 32767(--) 32767(--) 32767(--) 32767(--) 
6 \NEWYORK 41 (03) * 52 (02) 87 (05) 135(05) 32767(--) 
7 \QA 33 (03) 33 (03) 23 (01) * 117(03) 32767(--) 
8 \LA 104 (04) 104 (04) 140 (04) 94(02)* 32767 (--) 
9 \CORP 5 (01) * 10 (02) 51 (03) 99(04) 32767(--) 
10 \PARIS 98 (02) * 103 (03) 144 (04) 192(05) 32767 (--) 
11 \TORONTO 28 (02) * 33 (03) 74 (04) 122(05) 32767(--) 
14 \LONDON 57 (03) 57 (03) 93 (03) 47(01)* 32767 (--) 
16 \SNMATEO 18 (02) * 23 (03) 64 (04) 112(04) 32767(--) 

PATHS NEIGHBOR LDEV STATUS 

1 \CORP (009) 22 READY (07,007) 

2 \CUPRTNO (002) 15 READY (06,006) 

3 \QA (007) 18 READY (05,010) 

4 \LONDON (014) 20 READY (04,009) 

a Te ~- (000) 14 NOT READY (248) 


The first column, path 1, has six asterisks: one next to neighboring 
system 9 and one each next to systems 4, 6, 10, 11, and 16. Because 
systems 4, 10, 11, and 16 are only two hops away from the selected 
system, we assume that all are connected to system 9. System 6 can be 
connected to any of these systems. 


The second column, path 2, has one asterisk next to neighboring system 
2. However, systems 6 and 9 are only two hops away from the selected 
system; we assume that these systems are connected to system 2. 


Figure 4-2 shows that systems 2, 6, 9, and 16 are interconnected; we 
can reach any of these systems through either path. The best path 

from the selected system to system 6 is path 1. Although the number 
of hops is greater by going through path 1, the travel time is less. 


The third column, path 3, has only one asterisk to indicate the 
neighboring system 7. Because no other system is two hops from the 
selected system through this path, we assume that system 7 is not a 
through system--that is, we cannot go through it to get to any other 
system. Any communication from system 3 over this path to any system 
other than system 7 bounces back to system 3. 


The fourth column, path 4, has only two asterisks, one next to the 
neighboring system 14 and one next to system 8. Because system 8 is 
only two hops away from the selected system, we assume that system 8 
is connected to system 14. Any communication from system 3 over this 
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path to any system other than 8 or 14 bounces back to system 3. 


From this information emerges a possible graph of this network, shown 
in Figure 4-2. This picture of the network shows the numbers used in 
SYSGEN to represent the line-speed time factors of the communication 
lines between systems. Adding these numbers along a path gives the 
result found in the sample MAPS display above. 


\DALLAS 


(23) 


\ 
ciate. \CUPRTNO 


\SN MATEO 


(93) 
(47) 


\ PARIS 


\NEW YORK 


Figure 4-2. Graph of Sample Network Interconnections 
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The PATHS command displays the status of a selected path and status of 
the lines comprising the path. The form of the command is: 


PATHS [ system ] 
, [PATH pathnum ] 


where 


system 


is a specific system name (e.g., \DALLAS) or system number 
(e.g., 3). Status information for all paths in the system 


will be shown. If this parameter is omitted, paths for the 
default system are displayed. 


PATH pathnum 


selects a specific path and displays its status. Omission of 
this parameter causes all paths to be displayed for the local 
system. 


This command displays the status of paths, and the lines comprising 
each path, relative to a selected system. If no system is specified, 
NETMON displays the status of paths relative to the default system. 
The form of the display is: 


NETWORK MONITOR - T9007E02 - (0O1JUL81) 
PATHS AT system (sss) # PATHS = nn TIME: date, time 
PATH NEIGHBOR LDEV TF PID LINE LDEV STATUS 
pathnum systema sss pathdev tt cpu-pin 


lineno linedev status 
lineno linedev status 


where 


system (sss) 


is the name or number of the system specified in the PATHS 


command. The local system is used as the default if no parameters 
are supplied with the command. 
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nn 


is the number of internodal connections radiating from the 
selected system. This number indicates the number of entries 
listed for the PATH column. 


date, time 


is the date and time at which the display was requested. 


pathnum 


is the path number for the particular entry displayed. 


systema sss 


is the name/number of the immediately adjacent system in this path 


pathdev 


is the logical device number of the path. 


tt 


is the time or weight factor for the path (depends on the number 
of lines per path and the configured line speeds). 


cpu-pin 


is the number of the processor module where the net line handler 
is executing and the number of the process in that processor. 


Lineno 


is the line number in a particular path. It can be one of 
several lines in the same path for multi-line. 


linedev 


is the logical device number of the line. 


status 


shows the status of the line in the form of a brief description 
and file system error number. For example, an error 66 indicates 
that a line downed by the operator caused a not ready condition. 
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The following example shows a network composed of three paths, two of 


which contain multiple lines. Because the PATHS command’s optional 
parameters are omitted, all paths for the local default system, \TS 
(003), are displayed. 


>PATHS 
PATHS AT \TS (003) # PATHS = 4 TIME: 15 MAR 1981 10:33 
PATH NEIGHBOR LDEV TF PID LINE LDEV STATUS 


1 \MANGO = (001) 10 35 (00,040) 


Af ll NOT READY (140) 
2 12 READY 
3 13 READY 
2 \SIBERIA(011) 20 5 (06,022) 
1 21 READY 
3 \MFG (032) 30 -- -- --- 
1 31 NOT READY (248) 
2 32 NOT READY (066) 
Bet etews -- (000) 0 -- ee 
where 
\TS (003) 


is the name and number of the system selected, in this example 
the default system. 


# PATHS = 4 


is the number of paths connected through this system 


PATH 1 


connects to neighbor system name/number \MANGO (001) and is 
accessed through logical device address LDEV 10. The time or 
weight factor, dependent on the number of lines, is TF 35. 

The processid PID is (00, 040). This path is composed of three 
lines that are accessed through logical device addresses LDEV 1l, 


12 and 13. Line 1, LDEV 11, is not ready - file management error 
140; lines 2 and 3, LDEV 12 and 13 are ready. 
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PATH 2 


connects to system name/number \SIBERIA (011), is ready, and its 
status characteristics are similar to those of PATH l. 


PATH 3 


connects to system name/number \MFG (032) and is accessed through 


LDEV 30. This path is not ready, as indicated by the null entry 
in the processid and factor TF --; both line 1 and 2, LDEV 31 and 


32, show a not ready status - file management error 248 and 066 
respectively. 


PATH 4 


this line was not brought up since the last system cold load, 
thus it shows null entries for all fields. 
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PERIOD Command 


The PERIOD command sets the sample-interval time (in seconds) used by 
the DISPLAY command. The form of the command is: 


PERIOD [sample] 


where 


sample 


is the number of seconds over which the sample is taken. The 
range for sample is 10 through 600. If this option is 
omitted, the current sample period is displayed. Where no 
sample period has been specified, NETMON assumes 60 seconds. 


CONSIDERATIONS. The sample-interval time occurs only after the 
completion of the last DISPLAY command and before the next request for 
node statistics is sent. In essence, the sample-interval is only a 
minimum time; it can be much longer. 
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PROBE Command 


The PROBE command displays the current paths from one or all of the 
remote systems to the selected system. The form of the command is: 


fe eg cy eee regs Feet eae ig SE ee eg ee ee ee ny Se ee el ee 
PROBE [ systeml ] 
, [{ PERIOD interval ] 
, [| SYSTEM system2 ] 


where 


is either a system name or a system number from which the 
probe is made. If this option is omitted, the local system 
is assumed. 


interval 
is the number of seconds to wait between probes. The range 
for interval is 1 through 600. The probes continue until the 
BREAK key is pressed. If this option is omitted, the probe 
is performed once. 
system2 
is either a system name or a system number to which the probe | 


is made. If this opticn is omitted, all systems in the 


systeml 
| 
| 
Pd network are probed. 


The format of the display is: 


NETPROBES AT \<system> (sss) TIME: date, time 
SYSTEM RETURN PATH 
sss \systema - \system - \system - \system - \system - * (ttttt) 


sss \systemb - \system - \system - \system - \system - * (ttttt) 
sss \systemc - \system - \system - \system - \system - * (ttttt) 


where 


system (sss) 


is the name and number of the system selected in the PROBE 
command. 
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time: date, time 


is the date and time that the PROBE was requested. 


\system - \system 


is the list of systems through which the probe is made. 


is the system selected in the PROBE command. 


ttttt 


is the round-trip time for the probe in hundredths of a second 
("tics"). 


EXAMPLES. The first example shows that system 20 (whose name 
is \FRANKFT) is only two hops away from \LONDON (system 18). 


>PROBE \LONDON, SYSTEM 20 
NETPROBES AT \LONDON (018) TIME: 24 FEB 1981, 12:38:25 


20 \FRANKFT - \SCHULNG - * (00020) 


The next example shows that only two systems, 2 and 7, are connected 
directly to the local system, which is \TS (003). Moreover, all 
systems except 7 are connected to system 3 through system 2. 


>PROBE 
NETPROBES AT \TS (003) TIME: 24 FEB 1981, 12:43:52 


PROBE TO \SAA ** FAILED 250 ** 

\CUPRTNO - * (00007) 

4 \DALLAS - \NEWYORK - \CHICAGO - \MFG - \CORP - \CUPRTNO - * (00053) 
5 \CHICAGO - \MFG - \CORP - \CUPRTNO - * (00028) 

6 \NEWYORK - \CHICAGO - \MFG - \CORP - \CUPRTNO - * (00039) 

7 \QA - * (00005) 
9 
0 


NO 


\CORP - \CUPRTNO - * (00010) 


10 \MFG - \CORP - \CUPRTNO - * (00009) 
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SHOW Command 


The SHOW command displays the systems selected with the ADD command. 
The form of the command is simply 


with no options. 
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STATS Command 
The STATS command displays detailed statistics that represent the 


communication occurring between the specified system and all the 
systems in the network. The form of the command is: 


STATS [ system ] 
where 


system 


is either a system name or a system number. If this option is 
omitted, the local system is assumed. 


The format of the display is: 


NETWORK STATISTICS AT \system (sss) 


SYSTEM LINKS (PKTS) SENT LINKS (PKTS) RCVD 
sss \systema nnnnn (ppppp) mmmmm (qqqqq) 
sss \systemb nnnnn(ppppp) mmmmm (qqqqq) 
sss \systemc nnnnn (ppppp) mmmmm {qaqqqq) 
where 

system 


is the system selected in the STATS command. 


sss 


is the system number. 


\systema 


is one of the systems that communicates with the selected 
system. 


nnonnan 


is the total number of link requests issued by this system 
Since the last cold-load; wraps around. 
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(PPPPP) 
is the total number of packets sent from this system excluding 
pass-through packets since the last cold-load; wraps around. 
mmmmm 
is the total number of link requests received by this system 
since the last cold-load; wraps around. 
(qqqqq) 
is the total number of packets received by this system since 


the last cold-load; wraps around. 


EXAMPLE. This example shows that only systems 2, 7, and 9 are 
communicating with the specified system, \TS (003). Moreover, the 
network traffic for system 3 passes through system 2. 


>STATS 3 
NETWORK STATISTICS AT \TS (003) 
SYSTEM LINKS (PKTS) SENT LINKS (PKTS) RCVD 
2 \CUPRTNO 469 (01133) 102 (01132) 
4 \DALLAS 0 (00000) 0 (00000) 
5 \CHICAGO 0 (00000) 0 (00000) 
6 \NEWYORK 0 (00000) 0 (00000) 
7 \QA 47 (00110) 8 (00110) 
9 \CORP 6 (00165) 54 (00114) 
10 \MFG 0 (00000) 0 (00000) 
13 \HWR2 0 (00000) 0 (00000) 
14 \HWR 0 (00000) 0 (00000) 
15 \HWR1 0 (00000) 0 (00000) 
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THRESHOLD Command 


The THRESHOLD command determines when to blink the rate of packets 
line in the display shown with the DISPLAY command. The THRESHOLD 
command checks the rate of packets in each sample period. When the 
difference between the previous rate of packets and the current rate 
reaches the specified percentage, the rate of packets line blinks for 
one sample period. The form of the command is: 


THRESHOLD [ percentage ] 


where 


percentage 


is the percentage difference to be met to start blinking the 
rate of packets line. If this option is omitted, the current 


threshold value is displayed. If no threshold is specified, 
NETMON assumes 50 percent. 
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Messages 


BACKUP PROCESS ALREADY EXISTS IN CPU nn 
attempted to issue a second BACKUP command 


BACKUP PROCESS CREATED IN CPU nn 
successful completion of the BACKUP command 


CENTRAL LOGGING INITIATED 
self-explanatory 


CENTRAL LOGGING TERMINATED 
self-explanatory 


COMMA EXPECTED 
self-explanatory 


CURRENT CENTRAL LOGGING SYSTEM IS: system (nnn) 
response to LOGCENTRAL command without parameters 


ILLEGAL CPU NUMBER 
backup processor number must be between 0 and 15 


ILLEGAL PARAMETER 
attempt to use the HELP command for an unknown command 


ILLEGAL SYSTEM NUMBER nnn 


system numbers must be within the range defined with system 
generation (SYSGEN) 


INVALID SYSTEM NAME 
system name is unknown, name is too long, backslash is missing, 
or name has special characters (e.g., an ampersand) 


INVALID SYSTEM NUMBER 


system numbers must be within the range defined with system 
generation (SYSGEN) 


MUST BE A NAMED PROCESS TO RUN NONSTOP 
the NAME option in the RUN command must be specified 


NCP ERROR nnn 


unable to communicate with the Network Control Process (NCP) 
because error nnn occured while fetching data for the MAPS 
command. 


NETMON BACKUP TAKEOVER 
occurs when running NonStop 


NETTRACE RCVD WAS BAD 
improperly formatted trace message received from a remote system 


4-34 


Network Management--NETMON Commands 
Messages 


NO CENTRAL LOGGING SYSTEM CURRENTLY ACTIVE 
response to LOGCENTRAL command without parameters 


NOMEM FOR NCP*READ 
unable to obtain space for a MAPS message 


NOMEM FOR NCP“WRITEREAD 
unable to obtain space for a PROBE message 


NO SYSTEMS AVAILABLE 


no paths exist to other systems in the netvork; STATS command 
cannot retrieve information 


NO SYSTEMS AVAILABLE FOR PROBING 
no paths exist to other systems in the network; PROBE command 
cannot retrieve information 


NO SYSTEMS SELECTED 
systems are designated with the ADD command 


NO SYSTEMS SELECTED FOR DISPLAY 
systems are designated with the ADD command 


PERIOD MUST BE BETWEEN 10 & 600 SECONDS 
self-explanatory 


PROBE TO system ** FAILED nnn ** 
file error nnn prevents the PROBE command from completing 


SYSTEM IS NOT CURRENTLY AVAILABLE 


system specified in the MAPS, PROBE, or STATS command is 
unavailable 


SYNTAX ERROR 
self-explanatory 


THIS IS THE CENTRAL LOGGING SYSTEM 
response to LOGCENTRAL command without parameters 


THRESHOLD IS nnn% 
response to THRESHOLD command without parameters 


THRESHOLD MUST BE BETWEEN 1 AND 100 PERCENT 
self-explanatory 


TOO MANY PARAMETERS 
self-explanatory 


TOO MANY SYSTEMS REQUESTED, LIMIT IS 16 
attempt to add more systems than can fit on a screen for a 
display 


UNABLE TO CREATE BACKUP PROCESS IN CPU nn 
occurs when running NonStop 
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UNKNOWN COMMAND 
self-explanatory 


UNKNOWN KEYWORD 
self-explanatory 
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Syntax Summary 


ADD ieee 

system [, system,...] 
BACKUPCPU cpu 
CPuS [ system ] 


DELETE eee 
system [ ,system,...] 


DISPLAY 
EXIT 
FC 


HELP [ ALL ] 
command 


LOGCENTRAL ee 
ON 
MAPS [ system ] 


PATHS [ system ] 
, { PATH pathnum ] 


PERIOD [sample] 
PROBE [ systeml ] 
, ({ PERIOD interval ] 
, [| SYSTEM system2 ] 
SHOW 
STATS [ system ] 


THRESHOLD [ percentage |] 
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NETWORK SECURITY 


This section discusses network security. The reader should already be 
familiar with one-system security as described in your system 
programming manual. 


Overview 


Security in a network is more restrictive than security on a single 
system. The security philosophy of the system--that the machine 
serves a community of cooperating, intelligent users--does not extend 


to a network, in which nothing about the remote-user community can be 
controlled or assumed. 


Therefore, while the security system on one system allows any 
operation that is not specifically prohibited, the security ona 
network prohibits any operation that is not specifically allowed. 
Prior cooperation between system managers at each node is required 
before a user at one system can access another. 


A user at system X wishing to access a file (disc file, device, or 
process) residing on system Y must satisfy each of these three 
requirements: 


e the user at system X must also be a user at system Y 


@e the user must have matching REMOTEPASSWORDS set up at both system X 
and system Y 


@® the user at X must have sufficient capability to access a disc file 
at Y. 


Each of these three security levels is discussed below. 


Global Knowledge of User IDs 


Each system user is known to the machine by a user name, such as 
ADMIN.BILL, and a user identifier, such as 8,4. 


A user has access to files on a remote system only if that user”’s name 
and ID are known to the remote system. 


Thus if ADMIN.BILL, whose user ID is 3,46, wishes to access a file on 


a remote system, the remote system must also have a user named 
ADMIN.BILL whose user ID is 3,46. 


Remote Passwords 


Once the user identifiers of network users have been added to each 


node, a system of remote passwords is used to specify whether remote 
access is permitted. 
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Each user ID has associated with it a set of remote passwords. One, 
specified with the command 


: REMOTEPASSWORD \this system name, remote password 


designates the password required for a remote user to access this 
system. The others, specified by 


: REMOTEPASSWORD \remote system name, access password 


define passwords used in your subsequent attempts to access remote 
systems; such an attempt is successful if the remote-access password 
you associate with the remote system matches the remote-owner password 
previously specified by the remote user. 


Each type of password consists of as many as eight nonblank 


characters. Control characters are allowed, and lowercase characters 
are not upshifted. 


Consider two systems in a network, named \A and \B. On each system, a 
user named ADMIN.BILL with user ID 3,46 has been defined. 


At system \A, a user types the commands 


:LOGON ADMIN.BILL 
: REMOTEPASSWORD \A, shazam 


"shazam" is ADMIN.BILL“s remote-owner password. From now on, a user 
logged onto a remote system as ADMIN.BILL must specify "shazam" as his 
remote-access password to access system \A. For example, a system \B 
user enters 


:LOGON ADMIN.BILL 
: REMOTEPASSWORD \A, shazam 


This user now has remote access to \A as ADMIN.BILL, and can now 
perform operations such as creating processes and accessing certain 
disc files. However, when \B can access \A but \A cannot access \B, 
the ability to create processes on \A is not useful. The process is 
liable to want to access the home terminal, which is an attempt to 
access \B from \A, which is not permitted. Once passwords for both 
directions of access are established, everything works. 


A remote password, once defined, remains in effect until modified by a 
subsequent REMOTEPASSWORD command. ADMIN.BILL can log off and then 
log on again without having to respecify his remote passwords. 


ADMIN.BILL, logged on at system \B, does not have quite the same 
status on \A as the ADMIN.BILL on \A. ADMIN.BILL on \B is a remote 
accessor of \A; consequently, he cannot access disc files on \A that 
specify "local access only". The next section explains disc file 
security. 
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Moreover, ADMIN.BILL on \A still has no access to system \B. For 
ADMIN.BILL to gain access to \B, a remote-owner password must be 
defined for ADMIN.BILL at \B, and matched by a remote-access password 
at \A. For example, at \B: 


LOGON ADMIN.BILL 
: REMOTEPASSWORD \B, aardvark 


and at \A: 


:LOGON ADMIN.BILL 
: REMOTEPASSWORD \B, aardvark 


Now ADMIN.BILL at \A can access \B. 
These considerations apply to remote passwords: 


e As in the example above, the absence of a remote-owner password 
prevents remote access as that user. Thus, if MARKET.SUE does not 
supply a remote-owner password, no remote user with the same user 
ID can access MARKET.SUE’s system. 


e The command 
: REMOTEPASSWORD \<system name> 


removes any previously designated password (either for the local 
system or a remote one). The command 


: REMOTEPASSWORD 
removes all remote passwords. 


@ A remote-access password can be issued before the corresponding 
remote-owner password. Remote access becomes legal as soon as both 
remote passwords have been defined (provided that they match). 


@e A remote password can be specified for a remote system even though 
that system is not currently known or connected to the user’s 
system. After the remote system is placed in the network and the 
remote user specifies the correct remote password, access to the 
remote system may begin. 


@e Remote passwords are independent of the regular passwords defined 
for each user. In the example above, ADMIN.BILL at either system 
could issue the command 


‘sPASSWORD <local password> 


to prevent unauthorized individuals from logging on as ADMIN.BILL 
on that system. 
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Disc File Security 


For each disc file, the user specifies the access level required to 
read, write, execute and purge the file. Access levels are set in one 
of two ways: 


e by using the FUP SECURE command; for example, 
:FUP SECURE MYFILE, "AGO-" 
@e by using SETMODE function 1, "set disc-file security"; bit fields 


in the first parameter 1 specify the read-, write-, execute-, and 
purge-access via numbers. 


Access levels "A", "G", "O", and "-" imply local access only: 
A any local user can have access 
G members of the file owner”s group 
0 owner only 


super-ID only 
Classes of network users "N", "C", and "U" are defined thus: 
e A network user (N) is any accessor on any system. 


e A community (C) is an "extended group" including any accessor, 
anywhere on the network, whose group id matches the owner”s group 
id. Thus, user 8,4 on system \NEWYORK and user 8,17 on system 
\DETROIT are members of the same community. 


e A user class (U) is an "extended owner"; it includes any accessor 
throughout the network whose user ID matches that of the owner. 
Thus, user 8,4 on \NEWYORK and user 8,4 on \DETROIT are members of 
the same user class. 


A disc file can have any of these levels specified for read-, write-, 
execute-, and purge-access, using the numeric value with the SETMODE 
procedure or the corresponding letter in the FUP SECURE command. The 
levels are summarized in Table 4-2. 


Table 4-2. Local and Remote Access Codes 


numeric value letter 
(SETMODE) (FUP) meaning 


any local accessor 
any local group member 
owner only 


any network accessor, local or remote 
any member of owner“s community 

any member of owner”s user class 
local super-ID 
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Except for the super-ID, the numeric values for network access are 
found by adding 4 to the corresponding local access levels. 


Note that SUPER.SUPER has no special authority to access remote files; 
no user, including SUPER.SUPER, can access a remote disc file having 
"A" security. 


Default File Security 


Users can specify their own default file security, which is 
automatically assigned to any files that they create. 


Default file security is set with the DEFAULT command of the command 
interpreter. For example, the commands 


:LOGON ADMIN. BILL 
:DEFAULT SSYSTEM.MYFILES, "NAOO" 
:LOGON ADMIN.BILL 


cause any disc files created by ADMIN.BILL to automatically have file 
security "NAOO". Note that until his next LOGON command, the user’“s 
old default disc file security remains in effect. 


EXAMPLES. The combination of user IDs, remote passwords, and disc 
file security lets users tailor network security to their specific 
needs. These examples demonstrate some possible ways to implement 
network security. 


Example 1 (Local and Remote Users): Accessors of a file are 
classified as either "local" or remote" with respect to that file. A 
local user is one who is logged on to the system on which the file 
resides; a remote user is one logged on to a different system. 


A remote accessor of a system can become a local accessor by simply 
running a command interpreter in the remote system, and logging on. 
For example, if ADMIN.BILL on \A has specified the proper remote 
password to gain access to system \B, he can issue the commands 


:WAKEUP OFF 
:\B.COMINT 
:LOGON ADMIN.BILL 


He is now logged on as the local ADMIN.BILL on system \B. Thus, he 
can access disc files on \B owned by ADMIN.BILL having security "O". 
This remote session is terminated with a control-Y or LOGOFF. In the 
case of a control-Y, the command interpreter then asks "Are you sure 
you want to stop your command interpreter on \B?" Reply YES to awaken 
the local command interpreter. In the case of a LOGOFF, the command 
interpreter simply responds with “Exiting from CI on system \B." 


System \B can prevent a remote user from becoming a local user in a 
number of ways. One method is to specify "A" as the "execute" 
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security for SSYSTEM.SYSTEM.COMINT, preventing anyone in any remote 
system from running the program file. 


Another way to prevent ADMIN.BILL, on \A, from logging on to \B is to 


simply give ADMIN.BILL at \B a local password that is unknown to 
ADMIN.BILL at \A. 


Example 2: Suppose that there are so many systems in the network that 
nobody wants to type all the required REMOTEPASSWORD commands, but it 
is important to deny network access to certain users. 


At each node, establish a user called NET.ACCESS, and issue the 
following commands: 


: LOGON NET.ACCESS 

: PASSWORD local password 

: REMOTEPASSWORD \system 1, global password 
: REMOTEPASSWORD \system 2, global password 


: REMOTEPASSWORD \system n, global password 


the global password is the same for all systems and is known only to 
the system managers; the local password is different for each system 
and is given to those users who are allowed to access the network. 


Only those users who know the local password can log on as NET.ACCESS. 
The command 


: LOGON NET.ACCESS, local password 


allows them to access remote files. 


Example 3 (Sub-networks): Ina large network, it may be desirable to 
allow users to access some nodes, but not others. For example, you 
might want to allow users on system \SANFRAN to be able to access 
systems \LA, \SEATTLE, and \CUPRTNO, but not \NEWYORK and \CHICAGO. 


In this case, the idea used in Example 1 can be extended to allow 
access to any number of subnets, where a subnet is defined simply as 
any collection of individual nodes. A user named NET.WEST is 
established at each node of the subnet, and a password scheme such as 


the one in Example 2 is used to allow certain users to log on as 
NET.WEST. 


Subnets implemented in this manner can be allowed to overlap or 
include one another. For example, \CHICAGO might be accessible 
from \NEWYORK, by logging on as NET.EAST, and from \PHOENIX, by 
logging on as NET.MIDWEST. Similarly, each node in the entire network 


might have a user NET.GLOBAL, who is allowed to access every other 
node. 
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Example 4 (Defining the Capabilities of SUPER.SUPER): On a single 
system, SUPER.SUPER is allowed access to any file. On a network, the 
user can define whether the powers of the super-ID are local, global, 
Or somewhere in-between. 


To make SUPER.SUPER a local super-ID only, do not issue a 
REMOTEPASSWORD command for SUPER.SUPER at any node. This prevents a 
remote super-ID from accessing the nodes files. 


To make SUPER.SUPER a global super-ID, issue, at each node, 
REMOTEPASSWORD commands as in Example 2, so that SUPER.SUPER can 
access files on remote systems, and give every SUPER.SUPER the same 
password. Now, if a disc file has security "A", "G", "O" or "-", a 
remote super-ID can still gain access to the file by running a command 
interpreter in the system containing the disc file, and logging on as 
the local SUPER.SUPER. 


To make SUPER.SUPER an in-between super-ID, issue, at each 

node, REMOTEPASSWORD commands as in Example 2, so that SUPER.SUPER can 
access files on remote systems. Additionally, issue each SUPER.SUPER 
a distinct password. Then, any disc file can be protected from remote 
access by giving it "A", "G", "O", or "-—" security; a remote 
SUPER.SUPER cannot log on as the local one, since the local super-ID“s 
password is unknown. 


Process Access 
Several security considerations relate to remote processes: 


@ With respect to a given system, each process in the network is 
either "local" or "remote", according to these rules: 


he dd 


- A process is remote if it is running in a remote system. 
- A process is remote if its creator is in a remote system. 
- A process is remote if its creator is remote. 


According to the second and third rules, even a process running in 
a particular system can be remote with respect to that system. 
These rules prevent a user from remotely running a process that 
creates another process that accesses a file whose security 
specifies "local access only". 


@ A remote process cannot suspend or activate a local process. A 
remote process cannot stop a local process, unless the local 
process's stop mode is 0 ("anyone can stop me"). 

e A remote process can not put a local process into DEBUG. 

It is possibile for a process that is remote with respect to the system 


in which it”s running to become local. For instance, Example l, 
above, characterized users as either local or remote on the basis of 
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where they are logged on. The example also showed how a user in 


system \A could become local with respect to \B by running a command 
interpreter at \B and logging on. 


Consider the command interpreter in \B. Its creator is the user’s 
command interpreter in \A; thus, the command interpreter in \B is 
remote with respect to \B. But the user”~s LOGON command causes that 
command interpreter to become local with respect to \B. Thus, if you 
allow the possibility of a process somehow making itself local with 
respect to the system in which it’s running, the concept of local and 
remote users becomes equivalent to the concept of local and remote 
processes: a user is local (remote) with respect to a given system if 
his command interpreter is local (remote) with respect to that system. 


A process that makes itself local with respect to the system in which 
it is running is said to "programmatically log on" to that system. 


Programmatic Logon (VERIFYUSER Procedure) 


Programmatic logon is accomplished by calling the VERIFYUSER 
procedure, which verifies a user”“s password and optionally allows a 
process to programmatically log on (i.e., make the user’s ID its own, 
and become local with respect to the system in which it is running). 


The call to VERIFYUSER is 
CALL VERIFYUSER ( user name or id, 
logon, 
default, 
default length) 


where 


user name or id, INT:ref:12, 


is an array containing either the name or user ID of the user 
to be verified or logged on, where either 


user name or id [0:3] group name, blank-filled 
user name or id [4:7] user name, blank-filled 
user name or id [8:11] password, blank-filled 


or 


[0].<0:7> 
[0].<8:15> 
[1:7] 
[8:11] 


group ID 

user ID 

zeros (ASCII nulls) 
password, blank-filled 
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logon, INT:value, 


if present, verifies the user and, if its value is nonzero, 
logs on; if it is zero, is does not log on. If this option 
is omitted, a value of 0 is understood. 


default, INT:ref:18, 


if present, is returned information regarding the user 
specified in user name or id: 


default [0:3] 
default [4:7] 
default [8].<0:7> 
default [8].<8:15> 
default [9:12] 
default [13:16] 
default [17] 


group name, blank-filled 

user name, blank-filled 

group ID 

user ID 

default volume, blank-filled 
default subvolume, blank-filled 
default file security, this: 


default [17].<4:6> = read (O0= "A" 4 = "N" ) 
default [17].<7:9> = write (1 = "6" 5 = "Cc" ) 
default [17].<10:12> = execute (2= "0" 6 = "U" ) 
default [17].<13:15> = purge ( J = "0 ) 


default length, INT, 


is the length, in bytes, of the default array. This number 
should always be specified as 36; in the future, new fields 
can be added to default, requiring default length to become 
larger. 


These condition code settings are effected by the VERIFYUSER 
procedure: 


e < (CCL) indicates that a buffer is out of bounds or an I/O error 
occurred on the user-ID file. 


(CCE) indicates a successful verification and/or logon. 


@e > (CCG) indicates that there is no such user, or the password is 
bad. 


CONSIDERATIONS. After a successful logon using this procedure, a 
process is considered to be local with respect to the system in which 
it is running. 


A process that passes a bad password to VERIFYUSER for the third time 
is suspended for 60 seconds. 
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EXAMPLE. 

USER := 3 *<<* 8 + 17; ! user ID 3,17 

USER[1] *:=* 0 & USER[1] FOR 6; ! all zeros 

USER[8] *:=* PASSWORD FOR 8; 

LOGON := 1; ! log this user on 

CALL VERIFYUSER( USER, LOGON, DEFAULT, 36 ); 

IF < THEN ... ! buffer or I/O error 

ELSE IF > THEN ... ! no such user, or bad password 
ELSE ... ! successful 


NETWORK MANAGEMENT CONSIDERATIONS 


To develop and manipulate an EXPAND network it is necessary to use 
several Tandem-supplied programs and subsystems. These programs 
include: SYSGEN, CUP, PUP, and XRAY. The following discussion gives a 


brief description of each program and points out any special 
considerations for their use. 


SYSGEN 


The System Generation (SYSGEN) program generates an Operating System. 
for a given hardware/software configuration. Network management 
considerations for running SYSGEN for an EXPAND network include: 


Maximum system number (max systems). This network global SYSGEN 
parameter specifies the maximum number of systems in the network 
and establishes an upper bounds on the system numbers that will be 
recognized. Peculiar results occur if the value of max systems is 
not agreed to by all systems in a network. 


Consider the example of a network composed of \SYSTEMA (90) and 
\SYSTEMB (10). If \SYSTEMA is assigned a max systems value of 100 
and \SYSTEMB is assigned a max systems value of 10, then \SYSTEMB 
will never recognize a connect message sent from \SYSTEMA because 
the max systems value for \SYSTEMA does not fall within the bounds 
specified for \SYSTEMB. 


Thus, even though connected properly in all other respects, the two 
systems will never be able to communicate. To resolve the problem, 
change the max systems values to be compatible in one or both 
systems and run another SYSGEN in the modified system(s). 


Establishing an EXPAND link using an X.25 line. As mentioned in 
Section 1 of this manual, it is possible to connect two systems 

via EXPAND using an X.25 network. To accomplish this you must 
perform the following three steps. First, SYSGEN an X.25 line with 
the correct subtype to connect to the specific vendor X.25 network 
(such as Telenet, Tymnet, Datapac, or Transpac). Next, SYSGEN an 
EXPAND line (type NET*X25) as a separate LDEV. After the system is 
running, use CUP to ADD the EXPAND line as a subdevice to the X.25 
line and to specify the various line parameters. (See CUP in the 
AXCESS DATA COMMUNICATIONS PROGRAMMING MANUAL. ) 
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e Line weight factor. The RECSIZE parameter contains the value of 
the line weight factor (recommended values are given in the SYSGEN 
section of the GUARDIAN Operating Manual). However, any value may 
be selected. In fact, the network manager may cause the NCP to 
select a new "best path" by assigning a RECSIZE value small enough 
where a particular path is always selected. 


e All lines in a multiline path must be in the same controller group 
and run in the same cpu. If lines are distributed across multiple 
controllers to increase reliability, performance could be reduced 
by a controller ownership switch to the backup cpu. An ownership 
Switch results if the following conditions are true: a non-EXPAND 
line (such as AM3270) connected to this controller group fails with 
an error in the range 210-226. Failure of a line in an EXPAND 
multi-line path, however, does not cause an ownership switch. 


CUP 

The Communications Utility Program (CUP) allows access to data 
communication lines in the EXPAND network environment. Operations 
performed by CUP include: 


@® initiate line traces via the TRACE command 


@e modify communication line or subdevice characteristics via the 
ALTER command 


e list the SYSGEN configured communication line handlers via the 
LISTLH command 


@ add communication subdevices to an existing line handler via 
ADD command 


ct 
oy 
1) 


e list attributes of a particular line, subdevice, or group of 
subdevices via the SHOW command 


e display line and subdevice statistics via the STATS command; 
optionally resets the statistics 


e display a previously generated TRACE output file via the DUMP 
command 


e display system-related network information via the SHOW command 


The CUP TRACE facility now allows the Network Control Process (NCP) as 


well as the line handler to be traced. The NCP supplies CUP with the 
following information: 


@e NCP messages sent and received on a network path 


¢ Action and state changes caused by the receipt or transmission of a 
message, Or an event (internal or external) on both an internodal 
path and end-to-end path. 
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The CUP STATS command displays statistical information for the default 
line; default established through CUP LINE command. Line statistics 
are useful in determining optimal values for configuration parameters: 


"NO BUFFER" indicates the number of times the L2 dedicated buffer 
was full. This is not an error, but a warning that the next frame 
will be discarded if the buffer is not emptied. If the count is 

> 10% of the number of I-frames received, the size of the L2 
dedicated buffer should be increased. 


"BUFFER USAGE" maintains a count of line handler usage of IOPOOL. 
If the value for BUFFER USAGE approaches the SYSGEN value specified 
for the processor, the configured size should be increased. 


The CONNECT and CLEAR commands establish and terminate connection to 
an X.25-type device. For a detailed description of how to use CUP, 
refer to the AXCESS Data Communications Programming Manual. 


PUP 


The Peripheral Utility Program (PUP) performs various functions 
related to the peripheral devices connected to the system. Those 
functions related to the EXPAND network include: 


the DOWN command removes a line/path from service. If ! is 
specified, any current activity on the line is aborted. If ! is 
not specified, the line is removed from service only if there is 
no current activity on the line. 


the UP command places a downed line/path back into service. For 
NET*X25 lines, connection to the network must have been made 
previously through CUP. 


the LISTDEV command displays configuration characteristics for a 
given line/path. 


PUP is described in the GUARDIAN Operating System Operations Manual. 


Console Logging Messages 


Two commands (CUP ALTER MSGON/MSGOFF and PUP CONSOLE ENABLE/DISABLE) 


work together to determine the manner in which network-related console 
messages are handled: 


the CUP ALTER MSGON/MSGOFF command may selectively enable/disable 
network messages (43, 46, 48, and 49); messages (44, 45 and 47) are 
always enabled. In the event that these messages are disabled, the 
NCP discontinues sending them to the operator process. This 
results in no message logging to the disc-resident operator log and 
a reduction of traffic queued to the operator process. Remote 
logging, however, overrides the CUP ALTER disable. In this case, 
the NCP simply sends all messages to the logcentral system. 
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e the PUP CONSOLE ENABLE/DISABLE command enables/disables the 
printing of the messages on the local system’s console. A 
preliminary scan by the NCP checks whether the CUP ALTER command 
has enabled/disabled the messages. If enabled through CUP, they 
are sent to the operator process where the PUP CONSOLE 
enable/disable message list is checked to determine whether to 
print or not print the message at the console. However, if 
disabled by CUP, the messages are never sent to the operator 


process, thus nullifying the effect of the PUP CONSOLE 
enable/disable. 


EXPAND Line Connection To An X.25 Line 


The following example shows how to bring up an EXPAND line connection 
to an X.25 line. It is assumed that the X.25 line ($X25LIN) and the 
EXPAND line (S$EXPLIN) have previously been defined through SYSGEN. 


PUP DOWN ! $X25LIN 
CUP 
> LINE $X25LIN 
> ALTER NETADDR 311041500091 
! NETADDR is the X25 network address for this line 


> ADD #NETLIN, PROTOCOL NET, TYPE (63,0), RECSIZE 256, 
LHLDEV 25, NEXTSYS 3, ADDR 311041500091, PORT 77 


RECSIZE is the EXPAND packet size in bytes 
LHLDEV is the logical device number for S$EXPLIN 


NEXTSYS is the system number of the EXPAND node connected 
by SEXPLIN 


ADDR is the X25 network address of the EXPAND subdevice on 
the other end of this virtual circuit 


PORT is the X25 port number on the line specified by NETADDR 


> EXIT 


PUP UP $X25LIN 
PUP UP SEXPLIN 


CUP 
> LINE $X25LIN 
> CONNECT #NETLIN 


! causes the EXPAND line handler to ask the X25 AXCESS method 


vw Faw 


! to place a call out to the address in subdevice #NETLIN 
> EXIT 
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XRAY 


XRAY is a tool for monitoring the performance of a Tandem system. 
XRAY monitors: 


@e cpu use 
e line use 
e NCP or line handler process use of system resources 


For detailed information on how to use XRAY, refer to the XRAY User’s 
Manual. 
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APPENDIX A 


FILE-MANAGEMENT ERROR LIST 


This appendix lists file-management errors individually by error 
number, giving a brief explanation of the meaning of each and a code 
for the device type associated with each error. These references 
correspond to devices as shown in this table: 


Device Type Explanation 


0 write to another process”s process“id 
1 operator console ($0) 
2 SRECEIVE 

disc 


E 


disc with ENSCRIBE file structure 
Magnetic tape 

line printer 

terminal: conversational or page mode 
data communications line (ENVOY) 
auto-call unit 

punched-card reader 

X.25 access method PTP protocol 

data communications line (AXCESS) 

data communications line (ENVOY ACP) 


e 
o 4) 
fo) 


3 
3 
4 
5 
6 
7 
7 
8 
9 
0 
1 


ae 
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Description 


Device Type 


W 


Ol 


15 


16 


17 


($12) 
($13) 
(%14) 
($15) 
($16) 


($17) 


(%20) 


($21) 


operation successful 


end-of-file 

operation not allowed on this type file 
failure to open or purge a partition 
failure to open an alternate key file 
failure to provide sequential buffering 
system message received 


process not accepting OPEN, CLOSE, 
CONTROL, or SETMODE messages 


operation successful (examine MCW for 
additional status information) 


file or record already exists 


file not in directory; record not in file 


file in use 
illegal filename specification 
device does not exist 


volume specification supplied does not 


match name of volume on which the file 
actually resides 


file number has not been opened 


paired-open was specified and the file 
is not open by the primary process, the 
parameters suppiied do not match the 
parameters supplied when the file was 
opened by the primary, or the primary 
process is not alive 


any 


3,4,6,8 
any 

3E 

3E 


3E 


Error 


18 


19 


20 


21 


22 


23 


24 


25 


26 


27 


28 


29 
30 


31 


32 


33 


(%22) 


(%23) 


($24) 
($25) 
($26) 


($27) 


($30) 
($31) 
($32) 
($33) 


($34) 


($35) 
(%36) 


(337) 
($40) 


($41) 
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Description 
the referenced system does not exist; 


no connection made to this system since 
the last cold load 


no more devices in logical device table 
attempted network access by a process 
with a five-character name, or a 
seven-character home terminal name 


illegal count specified 


application parameter or buffer address 
out of bounds 


illegal disc address 


privileged mode required for this 
operation 


AWAITIO or CANCEL attempted on "wait" 
file 


AWAITIO or CANCEL attempted ona file 
with no outstanding operations 


wait operation attempted when 
outstanding requests pending 


number of outstanding no-wait operations 


would exceed that specified at OPEN, or 
attempt to open a disc file or SRECEIVE 
with maximum number of concurrent 
operations greater than l 


missing parameter 


unable to obtain main memory space for a 


link control block 


unable to obtain SHORTPOOL space for a 
file system buffer area 


unable to obtain main memory space for a 


control block 


I/O process is unable to obtain IOPOOL 
space for an I/O buffer, or count too 
large for dedicated I/O buffer 


Device Type 


any 


any 


any 


any 


any 
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Al 


42 
43 
44 
45 
46 
47 
48 
49 

| 

| 

| 

| 


($51) 


($52) 
($53) 
($54) 
(355) 
($56) 
(357) 
($60) 


(361) 


" (62) 


(%63) 
(364) 
(365) 
(366) 
(367) 
(370) 
($71) 
($72) 
($73) 


operation timed out. AWAITIO did not 
complete within the time specified by 
its time limit parameter. If a OD time 
Limit (completion check) or -1 file 
number (any file) was specified, then 
the operation is considered incomplete. 
Otherwise, the operation is considered 
completed. 


checksum error on file synchronization 
block 


attempt to read from unallocated extent 
unable to obtain disc space for extent 
directory is full 

file is full 

invalid key specified 

key not consistent with file data 


security violation; remote password 
illegal or does not exist 


access violation 

directory error 

directory is bad 

error in disc free-space table 
file system internal error 

I/O error in disc free-space table 
I/O error in directory 

I/O error on volume label 

I/O error in file label 

disc free-space table is bad 
file is bad 


volume on which this file resides has 
been removed or device has been downed 


since the file was opened 


any 
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61 (%75) no file opens are permitted 3 
62 (%76) volume has been mounted, but mount order 3 
has not been given, file open not 

permitted 
63 (%77) volume has been mounted and mount is in 3 


64 (%100) progress, file open not permitted 


65 (%101) only special requests permitted 3 
66 (%102) device has been downed by operator or 1,3 - 8 
a hard failure occurred on controller 

70 (%106) continue file operation 0,3 

71 (%107) duplicate record 3E 

72 (%110) attempt to access unmounted partition 3 

73 (%111) file/record locked 3 

74 (%112) READUPDATE called for SRECEIVE and 2 


number of messages queued exceeds 
receive depth; or REPLY called with 
an invalid message tag; or REPLY 
called and no message is outstanding 


87 (%127) | waiting on a READ request and did not subdevice 
get it 10 

88 (%130) a CONTROL READ is pending; new READ subdevice 
invalid 10 


($131) READ after CONTROL completion came in subdevice 
too late 10 
($143) attempt to use microcode option that is 3 
not installed 
($144) device not ready 3,4,5,6,8 
(3145) no write ring 4 
($146) Paper out 5 
103 (%147) disc not ready due to power failure 3 


($156) 


only break access permitted 


operation aborted because of break 


(3157) 
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Error Description 


112 (%160) READ or WRITEREAD preempted by operator 
message 


Device Type 


120 (%170) | data parity error i1,3 -7 

121 (%171) data overrun error : - 8 

122 (%172) request aborted due to possible data 6, 9 

loss caused by a reset of the circuit 

123 (%173) sub-device busy ae ee 

124 (%174) a line reset is in progress a a 

130 (%202) illegal address to disc 3 

131 (%203) write check error from disc 3 

132 (%204) seek incomplete from disc 3 

133 (%205) access not ready on disc 3 

134 (%206) address comparison error on disc 3 

135 (%207) write protect violation with disc 3 
j 136 ($210) | unit ownership error (dual-port disc) | 3 | 
| 137 (%211) | controller buffer parity error | 6.*, 7.¥*, | 
| 10.*, i1.* | 
140 (%214) | acreage Seer iets cia Link ie yet | 6,7 : 

r ’ 

| | loss Be ee oe aicconneseicny | | 

145 (%221) card reader--motion check error 

146 (%222) card reader--read check error 8 

147 (%223) card reader--invalid Hollerith code read 8 

150 (%226) end-of-tape marker detected 4 

151 (%227) | runaway tape detected 4 
| 152 (%230) | unusual end--tape unit went off-line | 4 | 


153 (%231) tape drive power on 4 
— 
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154 


155 


157 
160 


161 
162 
163 


164 


165 


166 


167 


168 


($232) 


($233) 
($235) 
($240) 


($241) 
($242) 
(243) 


($244) 


($245) 


($246) 


(247) 


($250) 


BOT detected during backspace files or 4 
backspace records 

only nine-track tape permitted 4 

I/O process internal error 3 - 8 
request is invalid for line state Tet y Ali 
more than seven reads or seven writes LE? 
issued 

impossible event occurred for line state 7.*, 11.* 
operation timed out | bate Lie ® 


EOT received 7.0-7.3,7.8 


power at auto-call unit is off 7.56 

disconnect received 7.0-7.1, 
iit.* 

data line is occupied (busy) 7.56 

RVI received 7.0-7.3 

data line is not occupied after setting 7.56 

call request 

ENQ received 7.0-7.1, 
7.3, 7.9 

auto-call unit failed to set "present 7.56 

next digit" 

EOT received on line bid/select 7.0-7.1, 
Pesy- tas 

"data set status" is not set after 7.56 

dialing all digits 

NAK received on line bid/select 7.0-7.1, 
Le54 7.8 

auto-call unit failed to clear "present 7.56 


next digit" after "digit present" was 
set 
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169 


170 
171 
172 
173 
174 
175 

| 

| 

| 

| 


176 
L77 


178 


179 


180 


190 


($251) 


($252) 


($253) 


($254) 


($255) 


($256) 


(3257) 


($260) 
($261) 


($262) 


($263) 


(3264) 


(3276) 


($277) 


WACK received on line bid/select 


auto-call unit set "abandon call and 


retry" 


station disabled or station not defined 


no ID sequence received during circuit 


assurance mode 


invalid MCW entry number on WRITE 


no response received or bid/poll/select 


reply not proper for protocol 


maximum allowable NAKs received 
invalid MCW on WRITE 

WACK received after select 

aborted transmitted frame 

incorrect alternating ACK received 
command reject 

poll sequence ended with no responder 


text overrun 


no address list specified 


application buffer is incorrect 


control request pending or autopoll 
active 


unknown device status received 


invalid status received from device 


device power on 


terete ie, ene eeernnnn tine nar eittt nee aateeemn © rth since of NR Set inn 


7.0-7.1,7.3 


7.56 


11.* 


7.0-7.1 


11.40 


Vee 
11.* 


10.*, 


72%, 
LL * 


10.%, 


7.*, 10.* 
ile* 
1.2-7.3 
Lis* 
7.0-7.3 


L1.* 
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192 (%300) device is being exercised 


200 (%310) device is owned by alternate port 


201 (%311) the current path to the device is down; 
inter-processor bus, not network related 


an attempt was made to write to a 0 
non-existent process 


NOTE 


Errors 210 - 226 cause the line handler to check 
whether any other lines are active in the path. 
If other lines are active, the defective line is 
downed and an error 66 is reported. If no other 
lines are active, a processor switch occurs and 
retries the operation through the switched port. 


210 (%322) device ownership changed during operation] 1, 3-9, 


211 (%323) failure of CPU performing this operation any 


212 (%324) EIO instruction failure; controller 1, 3-9, 
failure 10.*, 11.%* 

213 (%325) channel data parity error; controller 1, 3-9, 
or channel failure 10.*, 11.* 

214 (%326) channel timeout; controller or channel l, 3-9, 
failure 10.*, 11.* 

215 (%327) I/O attempted to absent memory page 1, 3-9, 
10.*, 11.* 

216 (%330) Map parity error during this I/O 1, 3-9, 
10.*, 11.* 

217 (%331) memory parity error during this I/O 1, 3-9, 
10.*, 11.* 

218 (%332) interrupt timeout; controller failure, 1, 3-9, 
channel failure, line disconnect 10.*, 11.* 


between controller and modem, or loss 
of modem clock 


219 (%333) illegal device reconnection 1, 3-9, 
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220 (%334) protect violation 


221 ($335) | pad-in violation ‘1, 3-9, 


| 10.*, 11.* 
222 (%336) bad channel status from EIO instruction 1, 3-9, 
10.*, 11.% 
223 (%337) bad channel status from IIO instruction 1, 3-9, 
10.*, 11.% 
224 (%340) controller error 1, 3-9, 
10.*, 11.% 
225 (%341) no unit or multiple units assigned to 1, 3-9, 
same unit number 10.*, 11.* 
230 (%346) CPU power failed then restored 1, 3-9, 
10.*, 11.% 
231 (%347) controller power failed then restored 1, 3-9, 
10.*, 11.% 
240 (%350) network line handler error; operation any 
not started. Controller ownership 
switched to brother cpu prior to the 
request. Link request to backup; 
line handler is not the owner of the 
| | controller. 
| 241 (%351) | network protocol error: operation not any 
| started. Network Routing Table (NRT) 
| | entry not equal to path ldev; new 
line handler pid in NRT--retry. 
| 248 (%370) | a line-handler process failed and caused 


while this request was outstanding. The 
file system recovers from this error for 
files opened with non-zero sync depth. 


249 (%371) a network failure caused the controller 
ownership to be switched while this 
request was outstanding. The file system 
recovers from this error for files opened 


any 


i 
| 
| | 
| 
| | 
any | 
the controller ownership to be switched | 
with non-zero sync depth. | 
| | 


: 250 (%372) | the referenced system is down; not any 


currently connected to named system 


A-10 


File-Management Error List 


251 (%373) a network protocol error occurred 


300-511 errors are reserved for process 
application-dependent usage 


A-11 


APPENDIX B 


CONSOLE MESSAGES 


Appendix B contains a summary of the network-related messages that 
the communications i/o process and Network Control Process (NCP) send 
to the operator console. This appendix also provides a brief 
explanation of how to interpret the file management error indication 
for a modem status error (140), i/o bus error (218), and not ready 


(248). 
CONSOLE MESSAGES 
The general form of a console message is: 
[ msg no. ] [ timestamp FROM sender system no. sender cpu pin ]} 
message 
where 
msg no. 
is a system message number; generated by the system as opposed 
to being generated by an application 


timestamp 


is of the form: hour:minute day month year 


FROM sender system no. sender cpu pin 
indicate the system number in the network, processor module, 
and processid in which the message originated 


message 
is a message generated either by an application or the system 


Console Messages 


NOTE 


Entries for msg no., timestamp, FROM sender system 


no., sender cpu, and pin are represented by 


rather than repeating them for each console message. 
The Idev and %ccu entries indicate the logical device 
number and controller/unit number of the device 


causing the message. 


Driver Generated Messages 


The communications driver sends five network-related messages (04, 06 
through 09) to the operator console: 


04 tisaeut LDEV ldev [ %ccu ] ERROR dev status 


paraml param2 BEL 


an error occurred on the indicated device and the retry was 


unsuccessful. 


The entry for dev status contains the status 


returned by the device controller; param2 contains the file 


Management error number. 


The format of the dev status for the Byte Synchronous 


controller is: 


READ UNIT 


Power On 
Device Overrun 


WRITE UNIT 
-<0> = Power On -<Q> 
-<l> = Channel Underrun <> 
-<2> = Channel Abort ~<2> 
-<3> = Channel Parity Error ~<3> 
-<4> = Auto Poll Termination «<4> 
-<5> = Data Set Rdy Termination .<5> 
-<6> = Modem Loss - <6> 
.<7> = Byte Cnt Termination ~<7> 


Channel Abort 
unused 

BCC 
VRC Error 

Modem Loss 

Byte Cnt Termination 


- 
Error 


If Modem Loss is detected, dev status.<6> = 1, bits.<8:15> 


have the following meanings: 


WRITE UNIT 
-<8> = unused 
-<9> = unused 
-<l10> = unused 
-<ll> = unused 
~<12> = Modem Loss 
.<13> = Carrier status 
-<14> = Clear To Send status 
-<15> = Data Set Ready status 


-<8> 

~<9> 

-<10> 
-<1ll> 
-<12> 
e<i3> 
~<1l4> 
~<1l5> 


READ UNIT 


unused 

unused 

unused 

unused 

Modem Loss 

Carrier status 

Clear To Send status 
Data Set Ready status 
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If no Modem Loss is detected, dev status.<6> = 0, bits.<8:15> 


have the following meanings: 
WRITE UNIT 


-<8> 

~<9> 

-<l0> 
-<ll> 
~<12> 
-<13> 
~<l4> 
~<l5> 


state count 


The format of the dev status for 


controller is: 


WRITE UNIT 
-<O> = Power On 
-<l> = Channel Underrun 
»-<2> = Channel Abort 
-<3> = Channel Parity Error 
-<4> = Modem Loss 
-<5> =0 
-<6> = Transmit Underrun 
-<7> = No Encryption 
AUTOPOLL OPERATION 
-<0O> = 0 
-<l> = Channel Underrun 
-<2> $= Channel Abort 
-<3> = Channel Parity Error 
-<4> = Modem Loss 
-<5> = Autopoll Terminated 
-<6> = Transmit Underrun 
-<7> = 0 


If Modem Loss is detected, dev 


-<8> = DSR*, Data Set Ready (inverted) 
-<9> = CD*, Carrier Detect (inverted) 

-<l0> = CTS*, Clear To Send (inverted) 

-<ll> = Transmit Overrun 

-<12> = RS-422 

-<13> = Maintenance mode 

-<14> = RTS, Request To Send 

-<15> = DTR, Data Terminal Ready 


-<8> 

-<9> 

-<10> 
~<ll> 
~<12> 
-<13> 
-<1l4> 
~<15> 


the Bit 


-<Q> 
~<l> 
—<2> 
-<3> 
-<4> 
s<5> 
-<6> 
~< FP 


READ UNIT 


ETB/ETX sensed 
SOH/STX sensed 


state count 


Synchronous 


READ UNIT 


0 

Channel Underrun 
Channel Abort 

0 

Modem Loss 

Read Byte Overrun 
Receiver Overrun 
No Encryption 


MODEM CONTROL OPERATION 


-<0> 
~<l> 
~<2> 
.<3> 
-<4> 
~<5> 
-<6> 
e<J> 


ov ooocooo°o 


SR, Data Set Rdy Intrpt 


status.<4> = 1, bits.<8:15> 
indicate the modem status for the write and read units, and the 
autopoll and modem control operations: 
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If no Modem Loss is detected, dev 


status.<4> = 0, bits.<8:15> 
have the following meanings: 


WRITE UNIT READ UNIT 
~<8> -<8> = Receiver Error 
~<9> -<9> = ABC.<0>, Assembled Bit Count 
-<10> -<l0> = ABC.<1> 
-<1l> Ending State -<11l> = ABC.<2> 
-<12> Count -<l2> = Receiver Overrun Error 
-<13> -<13> = Abort/Go-Ahead char detected 
~<1l4> -<14> = Receiver End-of-Message 
~<15> -<15> = 0 

AUTOPOLL OPERATION MODEM CONTROL OPERATION 
-<8> = 0 -<8> = DSR*, Data Set Rdy (inverted) 
-<9> = 0 -<9> = CD*, Carrier Detect (inverted) 
-<1l0> = 0 -<l0> = CTS*, Clear To Send (inverted) 
-<ll> = 0 -<ll> = Transmit Overrun 
-<12> = 0 e-<1l2> = RS-422 
-<13> = 0 .<13> = Maintenance mode 
-<14> = End of Poll-List .<14> = RTS, Request To Send 
-<15> = End of Poll -<15> = DTR, Data Terminal Ready 


06 {...} LDEV ldev [ %ccu ] UP 
the device has been placed online following a PUP UP command 


07 {...} LDEV ldev [ %ccu ] DOWN (BEL) 


the device has been placed offline following a PUP DOWN command 
og {...} 4 ev [ $ccu ] STATL stl-f stl-f2 stl-£3 
09 {...} LDEV ldev [ $ccu ] STAT2 st2-fl st2-f2 st2-£3 


messages 08 and 09 report device statistical information. 
statistics are reported if a line”s error count exceeds its 
designated threshold value, or after a line is closed with a 


nonzero statistic value. The statistics message fields have the 
following meanings: 


These 


stl-fl 
stl-f2 
stl-f3 
st2-f1 
st2-f2 
st2-f£3 


of 
of 
of 
of 
of 
of 


number 
number 
number 
number 
number 
number 


messages sent 


NAKS received 
BCC errors 
format errors 
retries 


messages received 
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NCP Generated Messages 


The Network Control Process (NCP) sends twelve network-related 
messages (33 through 35, 43 through 49, 91 and 92) to the operator 
console: 


NOTE 


Message numbers 43, 46, 48 and 49 may be enabled or 
disabled by use of the CUP ALTER command. 


33 {...} LDEV ldev NET: LINE QUALITY ### 


indicates that the line handler has reported a change in line 
quality (greater than or equal to five percent) to the NCP. 


34 {...} NET: LOGGING AT SYS ### 


indicates the system, other than the local system, that the NCP 
sends the console log messages. See NETMON LOGCENTRAL command. 


35 {...} NET: LOCAL LOGGING RESUMED 


indicates that the NCP now sends the console log messages to the 
local system. See NETMON LOGCENTRAL command. 


43 {...} LDEV ldev NET: CONNECTION LOST TO SYS ### (xxx) (BEL) 
this message occurs for three reasons: 


xxx = 1, the NCP has found all paths to system ### are 
unavailable 


xxx = 4, an end-to-end protocol error reported by the line 
handler. The NCP attempts reconnect through the same path; 
if unsuccessful, a reconnect through an alternate path is 
attempted. 


xxx = 999, recovery from soft failure; related to path 
timing 


44 {...} LDEV ldev NET: LINE READY 
X25: 


indicates that the line handler is ready to accept network 
requests. For the Direct Connect line handler, line ready occurs 
after both line handlers (local and remote) have exchanged reset 
sequences. For the X.25 interface, line ready occurs after the 
line handler is informed of the establishment of a virtual circuit 
or learns of the circuit by querying the X.25 AXCESS process. 


Console Messages 


45 {...} LDEV ldev NET: LINE NOT READY, ERROR ### (BEL) 
X25: 


indicates existence of an error that the line handler cannot 
resolve through the normal retry mechanism. The line handler will 
not accept subsequent network requests; thus causing the NCP to 
attempt a reconnect through an alternate path. The error entry 
contains a file management error number that describes the 
condition that caused the message. 


46 {...} LDEV ldev NET: CONNECTED TO SYS ### 


indicates a successful connect exchange with the NCP at remote 
system ### 


47 {...} LDEV ldev NET: LVL 4 TIMEOUT TO SYS ### (BEL) 


indicates that the line handler failed to receive an end-to-end 
response within the configured timeout and retry values 


48 {...} NET: SYS ### CPU STATUS pppppppppppppppp (BEL) 


indicates a change in processor status at system ### has occurred. 
The p entry indicates the up/down (1/0) state of the processors in 
the system; leftmost number is processor 0 and rightmost is 
processor 15. 


49 {...} LDEV ldev NET: ### NOT RESPONDING (BEL) 


indicates that the NCP at the receiving system has not received 
a status message from the NCP at system ### for three time 
periods. The NCP looks for an alternate path. 


91 {...} LDEV ldev NET: DEVICE SUBTYPE INVALID 


occurs during system initialization time if ldev subtype is not 
equal to 0, 1, or 2. EXPAND will not run until the SYSGEN LDEV 
subtype is corrected. 


92 iscauet LDEV ldev NET: TOO MANY LINES GEN’D FOR THIS PATH 


occurs during system initialization time if ldev subtype is 
specified as one of the following: more than 1 path ldev, more 
than 1 path/line, or more than 8 line ldevs. EXPAND will not run 
until the SYSGEN configuration is corrected. 


Console Messages 


NETWORK LINE-ERROR DIAGNOSIS 


The following discussion provides a brief explanation of how to 
interpret the file management error indication for a modem status 


error (140), i/o bus error (218), and not ready (248). It is intended 
to aid in the diagnosis of line problems within the network. 


Modem Status Error (140) 

The Network Line Handler reports modem errors for these reasons: 
e Data Set Ready (DSR) not detected within 30 seconds. 

e DSR lost. 

e Carrier Detect (CD) lost. 


e Clear to Send (CTS) lost. 


Any of the above conditions cause a modem status error indicated by a 
file management error (140) or console message (04). In the case of 
the console message, interpretation of the dev status bits depends on 
whether a byte synchronous or bit synchronous controller is being 
used. 


For the Byte Synchronous controller, dev status.<13:15> indicate the 
reason for the modem status error. 


dev status.<13> Carrier Detect 


dev status.<l4> = Clear to Send 


dev status.<l15> 


Data Set Ready 


For the Bit Synchronous controller, dev status.<8:10> indicate the 
reason for the modem status error. 


dev status.<8> = DSR*, Data Set Ready (inverted) 


dev status.<9> = CD*, Carrier Detect (inverted) 


dev status.<l0> CTS*, Clear To Send (inverted) 


I/O Bus Error (218) 


The Network Line Handler reports 218 errors when a write interrupt 
does not occur within the level-2 time period. This error may 
indicate a controller problem but also occurs if the modem is not 
generating transmit-clock pulses. 
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Not Ready (248) 


The Network Line Handler reports error 248 when unable to establish 
level-2 communications or when all level-2 retries have been 
exhausted. Possible reasons for this error are: 


the other system is down. If an alternate path exists, the state 


of the other system can be determined by issuing a NETMON MAPS 
command. 


incorrect NEXTSYS parameters. This error occurs only on the 
initial connection but should not occur after that. 


garbled or no data in/out. By performing successive CUP STATS 
commands (one minute interval) and observing the counts for 
U-FRAMEs it can be determined whether data is being transmitted and 


received. The BCC error count indicates the presence of garbled 
receive data. 


If the CUP STATS commands do not indicate both send and receive 
data, place the local modem in analog loopback and observe the 
U-FRAME counts again. If both send and receive counts are 
incrementing, the local controller and modem are okay. If both 
systems check out, check the lines by first using the modem 
self-test, then observe the U-FRAME counts with the remote modem in 
digital loopback. If all tests indicate data is being transmitted 
and received, then a trace at both ends of the line should indicate 
the cause of the not ready condition. 
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